From nmav at gnutls.org  Mon Mar  6 08:04:30 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 06 Mar 2017 08:04:30 +0100
Subject: [gnutls-help] gnutls 3.3.27
Message-ID: <1488783870.18801.1.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.3.27. This is a bug-fix release on
the previous stable branch.

* Version 3.3.27 (released 2017-03-06)

** libgnutls: read the pin-value attribute if the p11-kit version allows it.

** libgnutls: Addressed integer overflow resulting to invalid memory write
???in OpenPGP certificate parsing. Issue found using oss-fuzz project:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=420 [GNUTLS-SA-2017-3A]

** libgnutls: Addressed crashes in OpenPGP certificate parsing, related
???to private key parser. No longer allow OpenPGP certificates (public keys)
???to contain private key sub-packets. Issue found using oss-fuzz project:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=354
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=360 [GNUTLS-SA-2017-3B]

** libgnutls: Addressed large allocation in OpenPGP certificate parsing, that
???could lead in out-of-memory condition. Issue found using oss-fuzz project,
???and was fixed by Alex Gaynor:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=392 [GNUTLS-SA-2017-3C]

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.??A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ compressed sources:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.27.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.27.tar.xz.sig

Note that it has been signed with my openpgp key:
pub???3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid??????????????????Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid??????????????????Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From nmav at gnutls.org  Mon Mar  6 08:05:39 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 06 Mar 2017 08:05:39 +0100
Subject: [gnutls-help] gnutls 3.5.10
Message-ID: <1488783939.18801.2.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.5.10. This is a bug fix release on the
3.5.x branch.

* Version 3.5.10 (released 2017-03-06)

** gnutls.pc: do not include libidn2 in Requires.private. The libidn2 versions
???available do not include libidn2.pc, thus the inclusion was causing pkg-config
???issues. Instead we include -lidn2 in Libs.private when compile against libidn2.

** libgnutls: optimized access to subject alternative names (SANs) in parsed
???certificates. The previous implementation assumed a small number of
???SANs in a certificate, with repeated calls to ASN.1 decoding of the extension
???without any intermediate caching. That caused delays in certificates with
???a long list of names in functions such as gnutls_x509_crt_check_hostname().
???With the current code, the SANs are parsed once on certificate import.
???Resolves gitlab issue #165.

** libgnutls: Addressed integer overflow resulting to invalid memory write
???in OpenPGP certificate parsing. Issue found using oss-fuzz project:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=420 [GNUTLS-SA-2017-3A]

** libgnutls: Addressed read of 1 byte past the end of buffer in OpenPGP
???certificate parsing. Issue found using oss-fuzz project:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=391

** libgnutls: Addressed crashes in OpenPGP certificate parsing, related
???to private key parser. No longer allow OpenPGP certificates (public keys)
???to contain private key sub-packets. Issue found using oss-fuzz project:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=354
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=360 [GNUTLS-SA-2017-3B]

** libgnutls: Addressed large allocation in OpenPGP certificate parsing, that
???could lead in out-of-memory condition. Issue found using oss-fuzz project,
???and was fixed by Alex Gaynor:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=392 [GNUTLS-SA-2017-3C]

** libgnutls: Print the key PIN value used by the HPKP protocol as per RFC7469
???when printing certificate information.

** libgnutls: gnutls_ocsp_resp_verify_direct() and gnutls_ocsp_resp_verify()
???flags can be set from the gnutls_certificate_verify_flags enumeration.
???This allows the functions to pass the same flags available for certificates
???to the verification function (e.g., GNUTLS_VERIFY_DISABLE_TIME_CHECKS or
???GNUTLS_VERIFY_ALLOW_BROKEN).

** libgnutls: gnutls_store_commitment() can accept flag
???GNUTLS_SCOMMIT_FLAG_ALLOW_BROKEN. This is to allow the function to operate
???in applications which use SHA1 for example, after SHA1 is deprecated.

** certtool: No longer ignore the 'add_critical_extension' template option if
???the 'add_extension' option is not present.

** gnutls-cli: Added LMTP, POP3, NNTP, Sieve and PostgreSQL support to the
???starttls-proto command. Patch by Robert Scheck.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.??A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ compressed sources:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.10.tar.xz.sig

Note that it has been signed with my openpgp key:
pub???3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid??????????????????Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid??????????????????Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From fgunbin at fastmail.fm  Mon Mar  6 17:18:05 2017
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Mon, 06 Mar 2017 19:18:05 +0300
Subject: [gnutls-help] [gnutls-devel] gnutls 3.5.10
In-Reply-To: <1488783939.18801.2.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Mon, 06 Mar 2017 08:05:39 +0100")
References: <1488783939.18801.2.camel@gnutls.org>
Message-ID: <m2k2828jlu.fsf@fgunbin.local>

Thanks for the release!

I've got problem building, it's something with guile.  I have
guile-2.0.14 built & installed.

File guile/src/guile-gnutls-v-2.la is present.

Thanks!
Filipp

...
  GUILEC   modules/gnutls.go
Backtrace:
In ice-9/eval.scm:
 432: 19 [eval # #]
In /usr/local/bin/guild:
  72: 18 [main #]
In srfi/srfi-1.scm:
 616: 17 [for-each #<procedure 10e765a00 at scripts/compile.scm:187:14 (file)> #]
In scripts/compile.scm:
 190: 16 [#<procedure 10e765a00 at scripts/compile.scm:187:14 (file)> "modules/gnutls.scm"]
In system/base/target.scm:
  59: 15 [with-target "x86_64-apple-darwin16.4.0" ...]
In system/base/compile.scm:
 152: 14 [compile-file "modules/gnutls.scm" #:output-file ...]
  43: 13 [call-once #<procedure 10e7ebc80 at system/base/compile.scm:56:5 ()>]
In ice-9/boot-9.scm:
 174: 12 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 11 [#<procedure 10e7ebc40 at system/base/compile.scm:58:9 ()>]
 155: 10 [#<procedure 10e7ebcc0 at system/base/compile.scm:153:8 (port)> #<closed: file 0>]
 218: 9 [read-and-compile #<input: modules/gnutls.scm 10> #:from ...]
 234: 8 [lp (#<tree-il #> #<tree-il #>) #<directory (gnutls) 10eb2aa00> ...]
 182: 7 [lp (#<procedure compile-tree-il (x e opts)>) (eval-when # # ...) ...]
In ice-9/boot-9.scm:
2412: 6 [save-module-excursion #<procedure 10eb6f3f0 at language/scheme/compile-tree-il.scm:29:3 ()>]
In language/scheme/compile-tree-il.scm:
  31: 5 [#<procedure 10eb6f3f0 at language/scheme/compile-tree-il.scm:29:3 ()>]
In ice-9/psyntax.scm:
1107: 4 [expand-top-sequence ((eval-when # # #)) () ((top)) ...]
 990: 3 [scan ((eval-when (expand load eval) (define %libdir #) ...)) () ...]
 279: 2 [scan ((load-extension # "scm_init_gnutls")) () ((top)) ...]
In unknown file:
   ?: 1 [load-extension "/Users/fgunbin/src/gnutls-3.5.10/guile/src/guile-gnutls-v-2" ...]
In ice-9/boot-9.scm:
 109: 0 [#<procedure 10e7ebc00 at ice-9/boot-9.scm:100:6 (thrown-k . args)> misc-error ...]

ice-9/boot-9.scm:109:20: In procedure #<procedure 10e7ebc00 at ice-9/boot-9.scm:100:6 (thrown-k . args)>:
ice-9/boot-9.scm:109:20: In procedure dynamic-link: file: "/Users/fgunbin/src/gnutls-3.5.10/guile/src/guile-gnutls-v-2", message: "file not found"
make[3]: *** [modules/gnutls.go] Error 1


From emailmandar at gmail.com  Fri Mar 10 06:44:01 2017
From: emailmandar at gmail.com (Mandar Joshi)
Date: Fri, 10 Mar 2017 11:14:01 +0530
Subject: [gnutls-help] GnuTLS always 'scans' all usb tokens
Message-ID: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>

Hello,

I have few ePass2003 Auto Tokens that I use for storing my encryption keys.

They work well except for the fact that when any application making
use of gnutls pkcs11 functions starts, all the connected tokens get
'scanned' even when a specific uri that exists on the system is
specified to a function like gnutls_pkcs11_obj_list_import_url4 (...)

I can see the light green led flash on the connected tokens for few
seconds. This doesn't happen in parallel, the 'scanning' happens one
by one thus causing a huge delay.

Is this expected behaviour or is there something in the application
that I should do differently ?

Regards
Mandar Joshi


From nmav at gnutls.org  Fri Mar 10 08:55:28 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 10 Mar 2017 08:55:28 +0100
Subject: [gnutls-help] GnuTLS always 'scans' all usb tokens
In-Reply-To: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>
References: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>
Message-ID: <CAJU7zaJG+LvPDxxMEtQnCfjj4Jq0KfwsOTpvZN4uNaNEtpFc1Q@mail.gmail.com>

On Fri, Mar 10, 2017 at 6:44 AM, Mandar Joshi <emailmandar at gmail.com> wrote:
> Hello,
>
> I have few ePass2003 Auto Tokens that I use for storing my encryption keys.
>
> They work well except for the fact that when any application making
> use of gnutls pkcs11 functions starts, all the connected tokens get
> 'scanned' even when a specific uri that exists on the system is
> specified to a function like gnutls_pkcs11_obj_list_import_url4 (...)
>
> I can see the light green led flash on the connected tokens for few
> seconds. This doesn't happen in parallel, the 'scanning' happens one
> by one thus causing a huge delay.

Most likely the URI that you provide is generic enough to cover all
the tokens, and thus they are all scanned for the object. You will
have to specify a URI which can be used to identify a unique token.
For example a uri 'pkcs11:id=01' is not unique, any token in the
system may match. You'll have at least to specify the token serial and
name (my guess is that your tokens have all the same name, but
different serial?). Use p11tool --list-tokens to figure out their
unique parts.

regards,
Nikos


From nmav at gnutls.org  Sat Mar 11 12:14:16 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 11 Mar 2017 12:14:16 +0100
Subject: [gnutls-help] GnuTLS always 'scans' all usb tokens
In-Reply-To: <CAC9_qu1T5=k-0FDNqAOW1wK=DZsNZO3HKdoPX7VgBdk7+djOQg@mail.gmail.com>
References: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>
 <CAJU7zaJG+LvPDxxMEtQnCfjj4Jq0KfwsOTpvZN4uNaNEtpFc1Q@mail.gmail.com>
 <CAC9_qu1T5=k-0FDNqAOW1wK=DZsNZO3HKdoPX7VgBdk7+djOQg@mail.gmail.com>
Message-ID: <1489230856.2177.2.camel@gnutls.org>

[resending on list]

On Sat, 2017-03-11 at 04:57 +0530, Mandar Joshi wrote:
> > 
> > Most likely the URI that you provide is generic enough to cover all
> > the tokens, and thus they are all scanned for the object. You will
> > have to specify a URI which can be used to identify a unique token.
> > For example a uri 'pkcs11:id=01' is not unique, any token in the
> > system may match. You'll have at least to specify the token serial
> > and
> > name (my guess is that your tokens have all the same name, but
> > different serial?). Use p11tool --list-tokens to figure out their
> > unique parts.
> 
> Thanks for the quick response NIkos. All the tokens I have are of the
> same make but they do have differente serial numbers.
> 
> This is the output of "p11tool --list-tokens"

Could you send me the output of the following?

```
export PKCS11SPY=/usr/lib/.../opensc-pkcs11.so
p11tool --provider /usr/lib/.../pkcs11-spy.so --export "a_cert_url"
```

The output of the export (the certificate) is not needed, only the
PKCS#11 commands that lead to that.

I'm afraid that these tokens as seen as different readers, and as the
scanning goes, any of these could potentially contain any URI. The
readers do not seem to be having any information reflected to the URI.
I can see some optimizations, but I do not believe they will have any
impact in your case.

regards,
Nikos



From emailmandar at gmail.com  Sat Mar 11 12:24:24 2017
From: emailmandar at gmail.com (Mandar Joshi)
Date: Sat, 11 Mar 2017 16:54:24 +0530
Subject: [gnutls-help] GnuTLS always 'scans' all usb tokens
In-Reply-To: <1489230856.2177.2.camel@gnutls.org>
References: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>
 <CAJU7zaJG+LvPDxxMEtQnCfjj4Jq0KfwsOTpvZN4uNaNEtpFc1Q@mail.gmail.com>
 <CAC9_qu1T5=k-0FDNqAOW1wK=DZsNZO3HKdoPX7VgBdk7+djOQg@mail.gmail.com>
 <1489230856.2177.2.camel@gnutls.org>
Message-ID: <CAC9_qu1+yFzzytMYGqJ9xvt=E=eH4_6vU03N3Ji3Qh4jX0pbfw@mail.gmail.com>

> export PKCS11SPY=/usr/lib/.../opensc-pkcs11.so
> p11tool --provider /usr/lib/.../pkcs11-spy.so --export "a_cert_url"
> ```
I have attached the output. Please have a look.

Thanks
Mandar Joshi
-------------- next part --------------
$ p11tool --provider /usr/lib64/pkcs11-spy.so --export "pkcs11:model=PKCS%2315;manufacturer=EnterSafe;serial=2123110000050003;token=Company1SView2%20%28User%20PIN%29;id=%7c%d2%88%1a%23%88%9e%65%e3%ad%35%21%0d%4c%e8%77%2e%db%3b%38;object=CACertificate;type=cert"


*************** OpenSC PKCS#11 spy *****************
Loaded: "/usr/lib64/opensc-pkcs11.so"

0: C_GetFunctionList
2017-03-11 16:49:44.709
Returned:  0 CKR_OK

1: C_Initialize
2017-03-11 16:49:44.709
[in] pInitArgs = 0x563714387a10
     flags: 2
       CKF_OS_LOCKING_OK
Returned:  0 CKR_OK

2: C_GetInfo
2017-03-11 16:49:50.670
[out] pInfo: 
      cryptokiVersion:         2.20
      manufacturerID:         'OpenSC Project                  '
      flags:                   0
      libraryDescription:     'OpenSC smartcard framework      '
      libraryVersion:          0.16
Returned:  0 CKR_OK

3: C_GetSlotList
2017-03-11 16:49:50.670
[in] tokenPresent = 0x1
[out] pSlotList: 
Slot 0
Slot 4
[out] *pulCount = 0x2
Returned:  0 CKR_OK

4: C_GetTokenInfo
2017-03-11 16:49:50.670
[in] slotID = 0x0
[out] pInfo: 
      label:                  'Company1Sca (User PIN)          '
      manufacturerID:         'EnterSafe                       '
      model:                  'PKCS#15         '
      serialNumber:           '21231F4080048019'
      ulMaxSessionCount:       0
      ulSessionCount:          0
      ulMaxRwSessionCount:     0
      ulRwSessionCount:        0
      ulMaxPinLen:             16
      ulMinPinLen:             4
      ulTotalPublicMemory:     -1
      ulFreePublicMemory:      -1
      ulTotalPrivateMemory:    -1
      ulFreePrivateMemory:     -1
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      time:                   '                '
      flags:                   40d
        CKF_RNG                          
        CKF_LOGIN_REQUIRED               
        CKF_USER_PIN_INITIALIZED         
        CKF_TOKEN_INITIALIZED            
Returned:  0 CKR_OK

5: C_GetSlotInfo
2017-03-11 16:49:50.689
[in] slotID = 0x0
[out] pInfo: 
      slotDescription:        'FT ePass2003Auto 00 00          '
                              '                                '
      manufacturerID:         'FT                              '
      hardwareVersion:         50.2
      firmwareVersion:         0.0
      flags:                   7
        CKF_TOKEN_PRESENT                
        CKF_REMOVABLE_DEVICE             
        CKF_HW_SLOT                      
Returned:  0 CKR_OK

6: C_GetTokenInfo
2017-03-11 16:49:50.690
[in] slotID = 0x4
[out] pInfo: 
      label:                  'Company1SView2 (User PIN)       '
      manufacturerID:         'EnterSafe                       '
      model:                  'PKCS#15         '
      serialNumber:           '2123110000050003'
      ulMaxSessionCount:       0
      ulSessionCount:          0
      ulMaxRwSessionCount:     0
      ulRwSessionCount:        0
      ulMaxPinLen:             16
      ulMinPinLen:             4
      ulTotalPublicMemory:     -1
      ulFreePublicMemory:      -1
      ulTotalPrivateMemory:    -1
      ulFreePrivateMemory:     -1
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      time:                   '                '
      flags:                   40d
        CKF_RNG                          
        CKF_LOGIN_REQUIRED               
        CKF_USER_PIN_INITIALIZED         
        CKF_TOKEN_INITIALIZED            
Returned:  0 CKR_OK

7: C_GetSlotInfo
2017-03-11 16:49:50.706
[in] slotID = 0x4
[out] pInfo: 
      slotDescription:        'FT ePass2003Auto 01 00          '
                              '                                '
      manufacturerID:         'FT                              '
      hardwareVersion:         50.2
      firmwareVersion:         0.0
      flags:                   7
        CKF_TOKEN_PRESENT                
        CKF_REMOVABLE_DEVICE             
        CKF_HW_SLOT                      
Returned:  0 CKR_OK

8: C_OpenSession
2017-03-11 16:49:50.707
[in] slotID = 0x4
[in] flags = 0x4
pApplication=(nil)
Notify=(nil)
[out] *phSession = 0x5637143b1350
Returned:  0 CKR_OK

9: C_FindObjectsInit
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] pTemplate[4]: 
    CKA_ID                00005637143b1b20 / 20
    00000000  7C D2 88 1A 23 88 9E 65 E3 AD 35 21 0D 4C E8 77  |...#..e..5!.L.w
    00000010  2E DB 3B 38                                      ..;8            
    CKA_LABEL             00005637143b1b00 / 13
    43414365 72746966 69636174 65
     C A C e  r t i f  i c a t  e
    CKA_CLASS             CKO_CERTIFICATE      
    CKA_CERTIFICATE_TYPE  CKC_X_509
Returned:  0 CKR_OK

10: C_FindObjects
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x1
Object 0x5637143af5e0 matches
Returned:  0 CKR_OK

11: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_WRAP              00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_WRAP              00007ffc16e01cce / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

12: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_UNWRAP            00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_UNWRAP            00007ffc16e01cce / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

13: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_PRIVATE           00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_PRIVATE           False
Returned:  0 CKR_OK

14: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_TRUSTED           00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_TRUSTED           00007ffc16e01cce / 1
    00000000  00                                               .               
Returned:  0 CKR_OK

15: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_SENSITIVE         00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_SENSITIVE         00007ffc16e01cce / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

16: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_EXTRACTABLE       00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_EXTRACTABLE       00007ffc16e01cce / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

17: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_NEVER_EXTRACTABLE 00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_NEVER_EXTRACTABLE 00007ffc16e01cce / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

18: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_CERTIFICATE_CATEGORY  00007ffc16e01cd0 / 8
[out] pTemplate[1]: 
    CKA_CERTIFICATE_CATEGORY  00007ffc16e01cd0 / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

19: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_ALWAYS_AUTHENTICATE  00007ffc16e01cce / 1
[out] pTemplate[1]: 
    CKA_ALWAYS_AUTHENTICATE  00007ffc16e01cce / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

20: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_LABEL             00007ffc16e01dd0 / 128
[out] pTemplate[1]: 
    CKA_LABEL             00007ffc16e01dd0 / 13
    43414365 72746966 69636174 65
     C A C e  r t i f  i c a t  e
Returned:  0 CKR_OK

21: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_ID                00007ffc16e01e50 / 128
[out] pTemplate[1]: 
    CKA_ID                00007ffc16e01e50 / 20
    00000000  7C D2 88 1A 23 88 9E 65 E3 AD 35 21 0D 4C E8 77  |...#..e..5!.L.w
    00000010  2E DB 3B 38                                      ..;8            
Returned:  0 CKR_OK

22: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_VALUE             0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_VALUE             0000000000000000 / 506
Returned:  0 CKR_OK

23: C_GetAttributeValue
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
[in] hObject = 0x5637143af5e0
[in] pTemplate[1]: 
    CKA_VALUE             00005637143b1dd0 / 506
[out] pTemplate[1]: 
    CKA_VALUE             00005637143b1dd0 / 506
    00000000  30 82 01 F6 30 82 01 5F A0 03 02 01 02 02 0C 58  0...0.._.......X
    00000010  8C 12 3D 13 C5 4C 4D 27 D7 9C F5 30 0D 06 09 2A  ..=..LM'...0...*
    00000020  86 48 86 F7 0D 01 01 0B 05 00 30 19 31 17 30 15  .H........0.1.0.
    00000030  06 03 55 04 03 13 0E 47 6E 75 54 4C 53 20 74 65  ..U....GnuTLS te
    00000040  73 74 20 43 41 30 1E 17 0D 31 37 30 31 32 38 30  st CA0...1701280
    00000050  33 33 38 33 37 5A 17 0D 31 38 30 31 32 38 30 33  33837Z..18012803
    00000060  33 38 33 37 5A 30 19 31 17 30 15 06 03 55 04 03  3837Z0.1.0...U..
    00000070  13 0E 47 6E 75 54 4C 53 20 74 65 73 74 20 43 41  ..GnuTLS test CA
    00000080  30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01  0..0...*.H......
    00000090  05 00 03 81 8D 00 30 81 89 02 81 81 00 D0 E9 3C  ......0........<
    000000A0  8E 73 76 DA 67 FA 30 39 EE 04 35 0F 5E C5 94 F1  .sv.g.09..5.^...
    000000B0  DE 6A 72 AF 86 58 55 97 D3 70 4E 6B 79 19 90 C7  .jr..XU..pNky...
    000000C0  C9 5D 8B E9 03 76 C1 A8 C4 A9 DE 64 A0 8D 06 D7  .]...v.....d....
    000000D0  53 6D 11 92 11 D0 F6 53 84 6F 9D 8F 0A CA 55 53  Sm.....S.o....US
    000000E0  75 4A 51 1C 00 CD 49 23 63 71 2B B0 8F 79 51 67  uJQ...I#cq+..yQg
    000000F0  51 E8 14 51 9A 0F 8E 00 70 E4 86 03 31 B8 83 6E  Q..Q....p...1..n
    00000100  74 BC E4 E1 6D 48 C6 6D 0B 81 EB F7 4D D0 22 AA  t...mH.m....M.".
    00000110  D0 C5 2A 8A ED A0 66 5A BF 31 DE 22 E7 02 03 01  ..*...fZ.1."....
    00000120  00 01 A3 43 30 41 30 0F 06 03 55 1D 13 01 01 FF  ...C0A0...U.....
    00000130  04 05 30 03 01 01 FF 30 0F 06 03 55 1D 0F 01 01  ..0....0...U....
    00000140  FF 04 05 03 03 07 04 00 30 1D 06 03 55 1D 0E 04  ........0...U...
    00000150  16 04 14 7C D2 88 1A 23 88 9E 65 E3 AD 35 21 0D  ...|...#..e..5!.
    00000160  4C E8 77 2E DB 3B 38 30 0D 06 09 2A 86 48 86 F7  L.w..;80...*.H..
    00000170  0D 01 01 0B 05 00 03 81 81 00 AB A1 5E 65 2D A4  ............^e-.
    00000180  CC A6 02 3E F8 6B 43 85 CD 30 26 B4 4B FC 90 7D  ...>.kC..0&.K..}
    00000190  E9 FE CD 8F 5A 92 1D 49 7F 4D 33 AE 92 05 90 EB  ....Z..IM3.....
    000001A0  8A C6 22 91 2D 9C F0 BC 0B 3B A8 D2 0F 01 FD 71  ..".-....;.....q
    000001B0  06 5E 1A EC 75 61 12 CB 86 25 26 6C 01 19 09 A8  .^..ua...%&l....
    000001C0  DF E3 91 9A 86 18 F8 78 B5 2F DB 93 5B 71 9A EC  .......x./..[q..
    000001D0  A8 66 53 64 A4 E5 C5 E8 E0 DF 45 4A 1B CF 0E BA  .fSd......EJ....
    000001E0  7E 40 F9 A4 68 AC B3 D3 6E C6 CC 47 BC 54 57 8A  ~@..h...n..G.TW.
    000001F0  B5 E8 39 87 E1 2A 8A 45 4B 85                    ..9..*.EK.      
Returned:  0 CKR_OK

24: C_FindObjectsFinal
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
Returned:  0 CKR_OK

25: C_CloseSession
2017-03-11 16:49:50.707
[in] hSession = 0x5637143b1350
Returned:  0 CKR_OK
-----BEGIN CERTIFICATE-----
MIIB9jCCAV+gAwIBAgIMWIwSPRPFTE0n15z1MA0GCSqGSIb3DQEBCwUAMBkxFzAV
BgNVBAMTDkdudVRMUyB0ZXN0IENBMB4XDTE3MDEyODAzMzgzN1oXDTE4MDEyODAz
MzgzN1owGTEXMBUGA1UEAxMOR251VExTIHRlc3QgQ0EwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBANDpPI5zdtpn+jA57gQ1D17FlPHeanKvhlhVl9NwTmt5GZDH
yV2L6QN2wajEqd5koI0G11NtEZIR0PZThG+djwrKVVN1SlEcAM1JI2NxK7CPeVFn
UegUUZoPjgBw5IYDMbiDbnS85OFtSMZtC4Hr903QIqrQxSqK7aBmWr8x3iLnAgMB
AAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwcEADAdBgNVHQ4E
FgQUfNKIGiOInmXjrTUhDUzody7bOzgwDQYJKoZIhvcNAQELBQADgYEAq6FeZS2k
zKYCPvhrQ4XNMCa0S/yQfen+zY9akh1Jf00zrpIFkOuKxiKRLZzwvAs7qNIPAf1x
Bl4a7HVhEsuGJSZsARkJqN/jkZqGGPh4tS/bk1txmuyoZlNkpOXF6ODfRUobzw66
fkD5pGiss9NuxsxHvFRXirXoOYfhKopFS4U=
-----END CERTIFICATE-----



26: C_Finalize
2017-03-11 16:49:50.707
Returned:  0 CKR_OK


From n.mavrogiannopoulos at gmail.com  Sat Mar 11 12:31:00 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 11 Mar 2017 12:31:00 +0100
Subject: [gnutls-help] GnuTLS always 'scans' all usb tokens
In-Reply-To: <CAC9_qu1+yFzzytMYGqJ9xvt=E=eH4_6vU03N3Ji3Qh4jX0pbfw@mail.gmail.com>
References: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>
 <CAJU7zaJG+LvPDxxMEtQnCfjj4Jq0KfwsOTpvZN4uNaNEtpFc1Q@mail.gmail.com>
 <CAC9_qu1T5=k-0FDNqAOW1wK=DZsNZO3HKdoPX7VgBdk7+djOQg@mail.gmail.com>
 <1489230856.2177.2.camel@gnutls.org>
 <CAC9_qu1+yFzzytMYGqJ9xvt=E=eH4_6vU03N3Ji3Qh4jX0pbfw@mail.gmail.com>
Message-ID: <1489231860.2177.4.camel@gmail.com>

On Sat, 2017-03-11 at 16:54 +0530, Mandar Joshi wrote:
> > export PKCS11SPY=/usr/lib/.../opensc-pkcs11.so
> > p11tool --provider /usr/lib/.../pkcs11-spy.so --export "a_cert_url"
> > ```
> 
> I have attached the output. Please have a look.

>From your log, I guess, the call to C_GetSlotList could be optimized,
but I don't know if it would be noticeable. You can try the patch at:
https://gitlab.com/gnutls/gnutls/merge_requests/298


regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Mon Mar 13 11:12:45 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 13 Mar 2017 11:12:45 +0100
Subject: [gnutls-help] GnuTLS always 'scans' all usb tokens
In-Reply-To: <CAC9_qu0jMg3EeOo4fbhzN+1PwG_brzbq=tiQubb-pP=5o2AuqQ@mail.gmail.com>
References: <CAC9_qu0SVC=fTTDuZ6-zNHT9HY3W-dsPQOSb2gJ3XS=+t9SWiA@mail.gmail.com>
 <CAJU7zaJG+LvPDxxMEtQnCfjj4Jq0KfwsOTpvZN4uNaNEtpFc1Q@mail.gmail.com>
 <CAC9_qu1T5=k-0FDNqAOW1wK=DZsNZO3HKdoPX7VgBdk7+djOQg@mail.gmail.com>
 <1489230856.2177.2.camel@gnutls.org>
 <CAC9_qu1+yFzzytMYGqJ9xvt=E=eH4_6vU03N3Ji3Qh4jX0pbfw@mail.gmail.com>
 <1489231860.2177.4.camel@gmail.com>
 <CAC9_qu0jMg3EeOo4fbhzN+1PwG_brzbq=tiQubb-pP=5o2AuqQ@mail.gmail.com>
Message-ID: <CAJU7zaKiQNOFwsv18q6ODXJrZUTm8ZDbrYd4=ZS8AU8WpCxZPA@mail.gmail.com>

On Sun, Mar 12, 2017 at 7:08 AM, Mandar Joshi <emailmandar at gmail.com> wrote:
>>
> Moving slightly off topic, are two such tokens connected to the same
> machine expected to work correctly?

Yes.

> I ask because, they are not working correctly over here. I use glib
> and gio and the result of my initial testing is that only the
> application that was started latest is able to make use of the tokens.
> The gio error from the non working application says
> --------------------------------------------------------------------------------------------------
> PIN required for token 'Company1Sca (User PIN)' with URL
> 'pkcs11:model=PKCS%2315;manufacturer=EnterSafe;serial=21231F4080048019;token=Company1Sca%20%28User%20PIN%29'
> ** (sca:10371): DEBUG: TLS handshake: Error performing TLS handshake:
> No supported cipher suites have been found.
> --------------------------------------------------------------------------------------------------
> Is there a solution to this problem?

You'd better check the debugging output of the library. Most likely
there is an issue with the keys you utilize.

regards,
Nikos


From rmbeer2 at gmail.com  Mon Mar 27 19:27:57 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Mon, 27 Mar 2017 14:27:57 -0300
Subject: [gnutls-help] I can't execute the lines from example server
Message-ID: <CAA0fXPvB9vz0Z_z-az+tNS4qS9qogZDuZ11j0ybUpL185Hwtiw@mail.gmail.com>

Have problem with this example of the Server:
https://www.gnutls.org/manual/html_node/Echo-server-with-X_
002e509-authentication.html#Echo-server-with-X_002e509-authentication

Get error in "PERFORMANCE:%SERVER_PRECEDENCE" and can't continue.

I unknown why fail, unknown how to continue for take any data about of the
problem. Anyone helpme with this?
I also remove osrp and crl lines and still not work. Not found the
SERVER_PRECEDENCE in the man help.
i test all in openssl s_server/s_client for all certificates of pair
key/cert for server and pair key/cert of client and with 1 CA for both. All
certs is OK. (Also use from example for client from other web of gnutls)

Never work with PERFOMANCE...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170327/0e4cb4e3/attachment.html>

From tzz at lifelogs.com  Wed Mar 29 19:26:38 2017
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Wed, 29 Mar 2017 13:26:38 -0400
Subject: [gnutls-help] GnuTLS cryptographic API questions
In-Reply-To: <1423401290.2022.3.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Sun, 08 Feb 2015 14:14:50 +0100")
References: <20150207153406.GA7383@debian>
 <1423387098.2022.1.camel@gnutls.org> <20150208120028.GA5557@debian>
 <1423401290.2022.3.camel@gnutls.org>
Message-ID: <87wpb83sfl.fsf_-_@lifelogs.com>

Hello! I am evaluating the integration of the GnuTLS cryptographic
functions into Emacs. My alternative is to use Nettle directly but I'd
rather use the GnuTLS API.

There are a few issues.

I found myself unable to list the ciphers, MACs, and digests supported.
Nettle exposes those lists but GnuTLS doesn't seem to. The problem with
an explicit list is that I end up with [1] which will be either too
limited (to support all platforms) or too aggressive. I don't think I
could maintain that list long-term, since it could change with every
GnuTLS release. How would you suggest I approach this for now?
Individual ifdefs?

I think these lists are available internally, so exposing them would be
very helpful going forward.

Also I had to manually map the MACs to the digests, there's no way to
tell which MACs don't have associated digests. Similarly there's no way
to tell which ciphers can be used for AEAD, but at least there's no
separate C type for AEAD ciphers. Maybe those correspondences could be
expressed by API functions so they don't have to be hard-coded?

Thanks
Ted

[1]
const gnutls_cipher_algorithm_t gnutls_ciphers[] =
  {
   GNUTLS_CIPHER_ARCFOUR_128,
   GNUTLS_CIPHER_3DES_CBC,
   GNUTLS_CIPHER_AES_128_CBC,
   GNUTLS_CIPHER_AES_256_CBC,
   GNUTLS_CIPHER_ARCFOUR_40,
   GNUTLS_CIPHER_CAMELLIA_128_CBC,
   GNUTLS_CIPHER_CAMELLIA_256_CBC,
   GNUTLS_CIPHER_AES_192_CBC,
   GNUTLS_CIPHER_AES_128_GCM,
   GNUTLS_CIPHER_AES_256_GCM,
   GNUTLS_CIPHER_CAMELLIA_192_CBC,
   GNUTLS_CIPHER_SALSA20_256,
   GNUTLS_CIPHER_ESTREAM_SALSA20_256,
   GNUTLS_CIPHER_CAMELLIA_128_GCM,
   GNUTLS_CIPHER_CAMELLIA_256_GCM,
   GNUTLS_CIPHER_RC2_40_CBC,
   GNUTLS_CIPHER_DES_CBC,
   GNUTLS_CIPHER_AES_128_CCM,
   GNUTLS_CIPHER_AES_256_CCM,
   GNUTLS_CIPHER_AES_128_CCM_8,
   GNUTLS_CIPHER_AES_256_CCM_8,
   GNUTLS_CIPHER_CHACHA20_POLY1305,
   GNUTLS_CIPHER_NULL
  };

const gnutls_mac_algorithm_t gnutls_mac_algorithms[] =
  {
   GNUTLS_MAC_MD5,
   GNUTLS_MAC_SHA1,
   GNUTLS_MAC_RMD160,
   GNUTLS_MAC_MD2,
   GNUTLS_MAC_SHA256,
   GNUTLS_MAC_SHA384,
   GNUTLS_MAC_SHA512,
   GNUTLS_MAC_SHA224,
   GNUTLS_MAC_SHA3_224,
   GNUTLS_MAC_SHA3_256,
   GNUTLS_MAC_SHA3_384,
   GNUTLS_MAC_SHA3_512,
   GNUTLS_MAC_AEAD,
   GNUTLS_MAC_UMAC_96,
   GNUTLS_MAC_UMAC_128,
   GNUTLS_MAC_NULL
  };

/* Note this list has to be the same length as gnutls_mac_algorithms! */
const gnutls_digest_algorithm_t gnutls_digest_algorithms[] =
  {
   GNUTLS_DIG_MD5,
   GNUTLS_DIG_SHA1,
   GNUTLS_DIG_RMD160,
   GNUTLS_DIG_MD2,
   GNUTLS_DIG_SHA256,
   GNUTLS_DIG_SHA384,
   GNUTLS_DIG_SHA512,
   GNUTLS_DIG_SHA224,
   GNUTLS_DIG_SHA3_224,
   GNUTLS_DIG_SHA3_256,
   GNUTLS_DIG_SHA3_384,
   GNUTLS_DIG_SHA3_512,
   GNUTLS_DIG_NULL,
   GNUTLS_DIG_NULL,
   GNUTLS_DIG_NULL,
   GNUTLS_DIG_NULL
  };


From nmav at gnutls.org  Thu Mar 30 11:52:44 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Mar 2017 11:52:44 +0200
Subject: [gnutls-help] GnuTLS cryptographic API questions
In-Reply-To: <87wpb83sfl.fsf_-_@lifelogs.com>
References: <20150207153406.GA7383@debian> <1423387098.2022.1.camel@gnutls.org>
 <20150208120028.GA5557@debian> <1423401290.2022.3.camel@gnutls.org>
 <87wpb83sfl.fsf_-_@lifelogs.com>
Message-ID: <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>

On Wed, Mar 29, 2017 at 7:26 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
> Hello! I am evaluating the integration of the GnuTLS cryptographic
> functions into Emacs. My alternative is to use Nettle directly but I'd
> rather use the GnuTLS API.
> There are a few issues.
>
> I found myself unable to list the ciphers, MACs, and digests supported.
> Nettle exposes those lists but GnuTLS doesn't seem to. The problem with
> an explicit list is that I end up with [1] which will be either too
> limited (to support all platforms) or too aggressive. I don't think I
> could maintain that list long-term, since it could change with every
> GnuTLS release. How would you suggest I approach this for now?
> Individual ifdefs?

Hi,
 I am not sure how do you intend to use such lists, run-time or
compile-time, however would enumeration through the API be sufficient?
If yes, you may want to check the algorithm enumeration functions such
as
gnutls_mac_list(), gnutls_cipher_list() etc.

> Also I had to manually map the MACs to the digests, there's no way to
> tell which MACs don't have associated digests.

There are separate gnutls_mac_list() and gnutls_digest_list() which
can be used to obtain the different sets.

> Similarly there's no way
> to tell which ciphers can be used for AEAD, but at least there's no

The gnutls_cipher_get_tag_size could be used to determine the AEAD
status (only AEAD ciphers have a tag).

regards,
Nikos


From tzz at lifelogs.com  Thu Mar 30 15:27:37 2017
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Thu, 30 Mar 2017 09:27:37 -0400
Subject: [gnutls-help] GnuTLS cryptographic API questions
In-Reply-To: <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Thu, 30 Mar 2017 11:52:44
 +0200")
References: <20150207153406.GA7383@debian>
 <1423387098.2022.1.camel@gnutls.org> <20150208120028.GA5557@debian>
 <1423401290.2022.3.camel@gnutls.org> <87wpb83sfl.fsf_-_@lifelogs.com>
 <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>
Message-ID: <87inmq51yu.fsf@lifelogs.com>

On Thu, 30 Mar 2017 11:52:44 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> you may want to check the algorithm enumeration functions such as
NM> gnutls_mac_list(), gnutls_cipher_list() etc.

Oh! Those are not listed in
https://www.gnutls.org/manual/html_node/Cryptographic-API.html#Cryptographic-API
or in
https://gnutls.org/manual/html_node/Cryptographic-Backend.html#Cryptographic-Backend
or in the children of https://gnutls.org/manual/html_node/Using-GnuTLS-as-a-cryptographic-library.html#Using-GnuTLS-as-a-cryptographic-library
but under
https://gnutls.org/manual/html_node/Core-TLS-API.html#Core-TLS-API and I
didn't see them.

So that's perfect. I had a feeling I was missing something :) Do you
think those functions could also be listed under the Cryptographic API
sections I cited?

NM> There are separate gnutls_mac_list() and gnutls_digest_list() which
NM> can be used to obtain the different sets.

Does it make sense to correlate MACs and digests, since digests are
currently a subset of MACs? You do that with AEAD ciphers (a subcase of
general ciphers).

Or do you expect there to be digests that don't have an associated MAC?

NM> The gnutls_cipher_get_tag_size could be used to determine the AEAD
NM> status (only AEAD ciphers have a tag).

Nice, thank you! Could you add that to the documentation, so it's
guaranteed that if the function returns non-zero, the cipher is AEAD?

Thanks again
Ted



From nmav at gnutls.org  Fri Mar 31 20:58:26 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 31 Mar 2017 20:58:26 +0200
Subject: [gnutls-help] GnuTLS cryptographic API questions
In-Reply-To: <87inmq51yu.fsf@lifelogs.com>
References: <20150207153406.GA7383@debian> <1423387098.2022.1.camel@gnutls.org>
 <20150208120028.GA5557@debian> <1423401290.2022.3.camel@gnutls.org>
 <87wpb83sfl.fsf_-_@lifelogs.com>
 <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>
 <87inmq51yu.fsf@lifelogs.com>
Message-ID: <CAJU7zaLrLMUkL+_d8M1kxx3_aK024aqCzETVAoKRPF4qGot9zQ@mail.gmail.com>

On Thu, Mar 30, 2017 at 3:27 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
> So that's perfect. I had a feeling I was missing something :) Do you
> think those functions could also be listed under the Cryptographic API
> sections I cited?

It's a historical reason they are in the Core API (crypto API didn't
exist at the time). Now moving them to crypto.h would break existing
software. I've added some text that several functions may not be
listed in crypto API. If you have a better suggestion I'd appreciate a
merge request.

> NM> There are separate gnutls_mac_list() and gnutls_digest_list() which
> NM> can be used to obtain the different sets.
>
> Does it make sense to correlate MACs and digests, since digests are
> currently a subset of MACs? You do that with AEAD ciphers (a subcase of
> general ciphers).

This correlation is only for HMACs. MACs like poly1305 and UMAC have
no equivalent digest.

> NM> The gnutls_cipher_get_tag_size could be used to determine the AEAD
> NM> status (only AEAD ciphers have a tag).
>
> Nice, thank you! Could you add that to the documentation, so it's
> guaranteed that if the function returns non-zero, the cipher is AEAD?

Done.

regards,
Nikos