From crypto-dev at idlecore.com  Sun Jun  8 11:49:46 2014
From: crypto-dev at idlecore.com (xor)
Date: Sun, 08 Jun 2014 10:49:46 +0100
Subject: [Cryptography-dev] Aggregate signatures
Message-ID: <1402220986.10216.12.camel@localhost>

I'm a programmer, I need a way to have several people sign the same
message, and then send that message to several other people. I'd like to
be able to scale 'several people' to up to a million, so a list of
individual signatures doesn't work so well. I'm not sure what
cryptographic tool I require, but I'm looking into aggregate signatures.
Something like this:

http://theory.stanford.edu/~dfreeman/cs259c-f11/finalpapers/aggregatesigs.pdf

I couldn't find however a single implementation, I couldn't find one in
openssl, nss, or anywhere else. Does anyone know of a decent
implementation? Does anyone know if there is even a standard?


From hs at ox.cx  Tue Jun 10 11:38:29 2014
From: hs at ox.cx (Hynek Schlawack)
Date: Tue, 10 Jun 2014 11:38:29 +0200
Subject: [Cryptography-dev] PyCA domain
Message-ID: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>

Hi,

since I?m considering to move service_identity into PyCA (comments 
welcome), I would like to suggest to grab pyca.io (which is currently 
free) and use it as our own namespace for our RTFD sites.  In this case 
service-identity.pyca.io.  I?m pretty sure that?s good for our 
braaaand (we wanted to push PyCA anyway in the ?cryptography? 
thread) and it would give us some uniformity (same for 
pyopenssl.pyca.io, bcrypt.pyca.io, potentially cryptography.pyca.io? 
etc, pp).

Opinions?
?h

From terrycwk1994 at gmail.com  Tue Jun 10 12:19:00 2014
From: terrycwk1994 at gmail.com (Terry Chia)
Date: Tue, 10 Jun 2014 18:19:00 +0800
Subject: [Cryptography-dev] PyCA domain
In-Reply-To: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
References: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
Message-ID: <CAGqxZSUyRNbNzHScFfvpFRX_9mkoBiu-vCcLv+HzBeUkcUk6=g@mail.gmail.com>

This sounds good to me but someone needs to take care of setting it up.
Managing the SSL certs for the various sub domains can be potentially
annoying.

On Tuesday, June 10, 2014, Hynek Schlawack <hs at ox.cx> wrote:

> Hi,
>
> since I?m considering to move service_identity into PyCA (comments
> welcome), I would like to suggest to grab pyca.io (which is currently
> free) and use it as our own namespace for our RTFD sites.  In this case
> service-identity.pyca.io.  I?m pretty sure that?s good for our braaaand
> (we wanted to push PyCA anyway in the ?cryptography? thread) and it would
> give us some uniformity (same for pyopenssl.pyca.io, bcrypt.pyca.io,
> potentially cryptography.pyca.io? etc, pp).
>
> Opinions?
> ?h
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140610/d62b1271/attachment.html>

From donald at stufft.io  Tue Jun 10 13:04:28 2014
From: donald at stufft.io (Donald Stufft)
Date: Tue, 10 Jun 2014 07:04:28 -0400
Subject: [Cryptography-dev] PyCA domain
In-Reply-To: <CAGqxZSUyRNbNzHScFfvpFRX_9mkoBiu-vCcLv+HzBeUkcUk6=g@mail.gmail.com>
References: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
 <CAGqxZSUyRNbNzHScFfvpFRX_9mkoBiu-vCcLv+HzBeUkcUk6=g@mail.gmail.com>
Message-ID: <8BD7A056-82AE-46C6-9F79-FA242E668F4B@stufft.io>

I imagine we?d just get a *.pyca.io certificate and be done with it.

+1 from me, I needed another similar thing to tab complete now that I have
pypi.io and pypa.io ;)

On Jun 10, 2014, at 6:19 AM, Terry Chia <terrycwk1994 at gmail.com> wrote:

> This sounds good to me but someone needs to take care of setting it up. Managing the SSL certs for the various sub domains can be potentially annoying. 
> 
> On Tuesday, June 10, 2014, Hynek Schlawack <hs at ox.cx> wrote:
> Hi,
> 
> since I?m considering to move service_identity into PyCA (comments welcome), I would like to suggest to grab pyca.io (which is currently free) and use it as our own namespace for our RTFD sites.  In this case service-identity.pyca.io.  I?m pretty sure that?s good for our braaaand (we wanted to push PyCA anyway in the ?cryptography? thread) and it would give us some uniformity (same for pyopenssl.pyca.io, bcrypt.pyca.io, potentially cryptography.pyca.io? etc, pp).
> 
> Opinions?
> ?h
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140610/e08a451f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140610/e08a451f/attachment.sig>

From jean-paul at hybridcluster.com  Tue Jun 10 13:18:39 2014
From: jean-paul at hybridcluster.com (Jean-Paul Calderone)
Date: Tue, 10 Jun 2014 07:18:39 -0400
Subject: [Cryptography-dev] PyCA domain
In-Reply-To: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
References: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
Message-ID: <5396E98F.7070808@hybridcluster.com>

On 06/10/2014 05:38 AM, Hynek Schlawack wrote:
> Hi,
>
> since I?m considering to move service_identity into PyCA (comments
> welcome), I would like to suggest to grab pyca.io (which is currently
> free) and use it as our own namespace for our RTFD sites.  In this
> case service-identity.pyca.io.  I?m pretty sure that?s good for our
> braaaand (we wanted to push PyCA anyway in the ?cryptography? thread)
> and it would give us some uniformity (same for pyopenssl.pyca.io,
> bcrypt.pyca.io, potentially cryptography.pyca.io? etc, pp).
>

I'm actively disinterested in a .io domain for pyopenssl.

Jean-Paul

> Opinions?
> ?h
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140610/34060691/attachment.sig>

From _ at lvh.io  Tue Jun 10 14:41:30 2014
From: _ at lvh.io (Laurens Van Houtven)
Date: Tue, 10 Jun 2014 14:41:30 +0200
Subject: [Cryptography-dev] PyCA domain
In-Reply-To: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
References: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
Message-ID: <CAE_Hg6bk0tBWmTE5GNH8Rt2rMKgxSA7DZeqDLi46Ufee7eVcgA@mail.gmail.com>

+1
On Jun 10, 2014 11:38 AM, "Hynek Schlawack" <hs at ox.cx> wrote:

> Hi,
>
> since I?m considering to move service_identity into PyCA (comments
> welcome), I would like to suggest to grab pyca.io (which is currently
> free) and use it as our own namespace for our RTFD sites.  In this case
> service-identity.pyca.io.  I?m pretty sure that?s good for our braaaand
> (we wanted to push PyCA anyway in the ?cryptography? thread) and it would
> give us some uniformity (same for pyopenssl.pyca.io, bcrypt.pyca.io,
> potentially cryptography.pyca.io? etc, pp).
>
> Opinions?
> ?h
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140610/729c629e/attachment.html>

From paul.l.kehrer at gmail.com  Tue Jun 10 14:54:07 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Tue, 10 Jun 2014 07:54:07 -0500
Subject: [Cryptography-dev] PyCA domain
In-Reply-To: <5396E98F.7070808@hybridcluster.com>
References: <76A40381-5E08-4327-9155-4D5FF80DF535@ox.cx>
 <5396E98F.7070808@hybridcluster.com>
Message-ID: <etPan.5396ffef.3d1b58ba.655@atlas.local>

I agree that we should probably pick up a domain. Like JP, I?m not a huge fan of the .io TLD, although looking around I?m not sure there?s a better option (pyca.ninja, pyca.dating!). py.ca is, of course, squatted already.

A wildcard is no problem though, so we can manage subdomains by not managing them at all.

On June 10, 2014 at 6:36:53 AM, Jean-Paul Calderone (jean-paul at hybridcluster.com) wrote:

On 06/10/2014 05:38 AM, Hynek Schlawack wrote:  
> Hi,  
>  
> since I?m considering to move service_identity into PyCA (comments  
> welcome), I would like to suggest to grab pyca.io (which is currently  
> free) and use it as our own namespace for our RTFD sites. In this  
> case service-identity.pyca.io. I?m pretty sure that?s good for our  
> braaaand (we wanted to push PyCA anyway in the ?cryptography? thread)  
> and it would give us some uniformity (same for pyopenssl.pyca.io,  
> bcrypt.pyca.io, potentially cryptography.pyca.io? etc, pp).  
>  

I'm actively disinterested in a .io domain for pyopenssl.  

Jean-Paul  

> Opinions?  
> ?h  
> _______________________________________________  
> Cryptography-dev mailing list  
> Cryptography-dev at python.org  
> https://mail.python.org/mailman/listinfo/cryptography-dev  


_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140610/fa056fa2/attachment-0001.html>

From donald at stufft.io  Thu Jun 19 00:32:18 2014
From: donald at stufft.io (Donald Stufft)
Date: Wed, 18 Jun 2014 18:32:18 -0400
Subject: [Cryptography-dev] PyNaCl
Message-ID: <A53BE833-1C1F-4612-9C5A-B4E1C29A316D@stufft.io>

I?ve just added cryptography-core to the collaborators for PyNaCl.

I don?t honestly have a lot of time to manage PyNaCl, most of my spare OSS time is chewed up with packaging stuff. If other people want to adopt it then that?s fine with me, if not then IDK what we should do with it.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140618/a617a7a9/attachment.sig>

From paul.l.kehrer at gmail.com  Thu Jun 19 00:33:48 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Wed, 18 Jun 2014 16:33:48 -0600
Subject: [Cryptography-dev] PyNaCl
In-Reply-To: <A53BE833-1C1F-4612-9C5A-B4E1C29A316D@stufft.io>
References: <A53BE833-1C1F-4612-9C5A-B4E1C29A316D@stufft.io>
Message-ID: <etPan.53a213cc.238e1f29.103a7@atlas>

Given that it?s (mostly) mature I don?t see a problem helping maintain it.

On June 18, 2014 at 4:32:27 PM, Donald Stufft (donald at stufft.io) wrote:

I?ve just added cryptography-core to the collaborators for PyNaCl.  

I don?t honestly have a lot of time to manage PyNaCl, most of my spare OSS time is chewed up with packaging stuff. If other people want to adopt it then that?s fine with me, if not then IDK what we should do with it.  


-----------------  
Donald Stufft  
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA  

_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140618/5596f116/attachment.html>

From alex.gaynor at gmail.com  Thu Jun 19 00:34:10 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Wed, 18 Jun 2014 15:34:10 -0700
Subject: [Cryptography-dev] PyNaCl
In-Reply-To: <A53BE833-1C1F-4612-9C5A-B4E1C29A316D@stufft.io>
References: <A53BE833-1C1F-4612-9C5A-B4E1C29A316D@stufft.io>
Message-ID: <CAFRnB2UXdzyzkPAspXWQkzcDKHWkuSGOuKP6Ku42o1+W2iG9hQ@mail.gmail.com>

I'm willing to continue to review PRs as they come in; but I probably can't
commit to maintaince beyond that.

Alex


On Wed, Jun 18, 2014 at 3:32 PM, Donald Stufft <donald at stufft.io> wrote:

> I?ve just added cryptography-core to the collaborators for PyNaCl.
>
> I don?t honestly have a lot of time to manage PyNaCl, most of my spare OSS
> time is chewed up with packaging stuff. If other people want to adopt it
> then that?s fine with me, if not then IDK what we should do with it.
>
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140618/c95f0deb/attachment.html>

From terrycwk1994 at gmail.com  Thu Jun 19 02:43:56 2014
From: terrycwk1994 at gmail.com (Terry Chia)
Date: Thu, 19 Jun 2014 08:43:56 +0800
Subject: [Cryptography-dev] PyNaCl
In-Reply-To: <CAFRnB2UXdzyzkPAspXWQkzcDKHWkuSGOuKP6Ku42o1+W2iG9hQ@mail.gmail.com>
References: <A53BE833-1C1F-4612-9C5A-B4E1C29A316D@stufft.io>
 <CAFRnB2UXdzyzkPAspXWQkzcDKHWkuSGOuKP6Ku42o1+W2iG9hQ@mail.gmail.com>
Message-ID: <CAGqxZSUxLdm=8V2-PsZ5zBy1A8x6X_fMCbf5YkNCfw1OHJYm_g@mail.gmail.com>

I can lend a hand maintaining it.

On Thu, Jun 19, 2014 at 6:34 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> I'm willing to continue to review PRs as they come in; but I probably can't
> commit to maintaince beyond that.
>
> Alex
>
>
> On Wed, Jun 18, 2014 at 3:32 PM, Donald Stufft <donald at stufft.io> wrote:
>>
>> I?ve just added cryptography-core to the collaborators for PyNaCl.
>>
>> I don?t honestly have a lot of time to manage PyNaCl, most of my spare OSS
>> time is chewed up with packaging stuff. If other people want to adopt it
>> then that?s fine with me, if not then IDK what we should do with it.
>>
>>
>> -----------------
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>

From carlos.garza at rackspace.com  Thu Jun 26 05:02:03 2014
From: carlos.garza at rackspace.com (Carlos Garza)
Date: Thu, 26 Jun 2014 03:02:03 +0000
Subject: [Cryptography-dev] help: pica cryptography get subjectAltNames
Message-ID: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>

                                                                              ^
    I'm trying to leverage the cryptography project and am trying to extract
the subjAltName extension from x509 certificates encoded as PEM. Does any 
one have any suggestions as to how I could do this?

More specifically I'm
trying to extract all dNSName entries from the general names of any x509
certs with the 2.5.29.17 extensions. I'm doing this with pyasn1 already
but I'm trying to do this via OpenSSL in hazmat. 


I see references to ASN1_IA5STRING *dNSName in the file
 "./cryptography/hazmat/bindings/openssl/x509v3.py" but no apparent code that extracts this.


I'd like some pointers as to how to add code to 
add to the cryptography/cryptography/hazmat/backends/openssl/backend.py
that can extract the dNSNames from the altNames extension from pen encoded X509 certs.
Any suggestions as to how I would do this?


From _ at webseducer.com  Thu Jun 26 10:06:41 2014
From: _ at webseducer.com (Laurens Van Houtven)
Date: Thu, 26 Jun 2014 10:06:41 +0200
Subject: [Cryptography-dev] help: pica cryptography get subjectAltNames
In-Reply-To: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>
References: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>
Message-ID: <0D41D9CE-DA70-43E9-ACA3-043CAC2A4C5B@lvh.cc>

Hi Carlos,


This sounds like a job for PyOpenSSL, which uses Cryptography internally. I think it has support for what you need, but even if there?s a bit missing, it probably makes a lot of sense to add it to PyOpenSSL, particularly since we hope to be releasing 0.15 soon.


hth
lvh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140626/055a2127/attachment.sig>

From paul.l.kehrer at gmail.com  Thu Jun 26 16:15:53 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 26 Jun 2014 08:15:53 -0600
Subject: [Cryptography-dev] help: pica cryptography get subjectAltNames
In-Reply-To: <0D41D9CE-DA70-43E9-ACA3-043CAC2A4C5B@lvh.cc>
References: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>
 <0D41D9CE-DA70-43E9-ACA3-043CAC2A4C5B@lvh.cc>
Message-ID: <etPan.53ac2b19.238e1f29.8543@atlas.local>

As lvh says, PyOpenSSL is the right tool for the job at this time. cryptography has no support for X509 parsing at a level above its C bindings. That will eventually change, but PyOpenSSL has tools for this right now.


On June 26, 2014 at 8:05:47 AM, Laurens Van Houtven (_ at webseducer.com) wrote:

Hi Carlos,  


This sounds like a job for PyOpenSSL, which uses Cryptography internally. I think it has support for what you need, but even if there?s a bit missing, it probably makes a lot of sense to add it to PyOpenSSL, particularly since we hope to be releasing 0.15 soon.  


hth  
lvh  
_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140626/c0ad7f54/attachment.html>

From carlos.garza at rackspace.com  Thu Jun 26 21:59:00 2014
From: carlos.garza at rackspace.com (Carlos Garza)
Date: Thu, 26 Jun 2014 19:59:00 +0000
Subject: [Cryptography-dev] help: pica cryptography get subjectAltNames
In-Reply-To: <etPan.53ac2b19.238e1f29.8543@atlas.local>
References: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>
 <0D41D9CE-DA70-43E9-ACA3-043CAC2A4C5B@lvh.cc>
 <etPan.53ac2b19.238e1f29.8543@atlas.local>
Message-ID: <687A9EFF-B892-4B7D-AFDF-B0B6083D5BC4@rackspace.com>

   That works out great for me. I didn't know if I had time right now to add functionality
to the cryptography project but I have a deadline. My first choice was to use pyasn1 and I already
have written utile to extract the altNames but I'll consider PyOpenSSL as I'm more mature
by now then when I first used it back in the python 2.4 days.

    Paul let me know when and how I can contribute to the hazmat code. It looks like a wonderful
project that I want to contribute out side of my work obligations. I'm impressed by the mathematics
behind it. Please advise me on when and how I can contribute. 

On Jun 26, 2014, at 9:15 AM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> As lvh says, PyOpenSSL is the right tool for the job at this time. cryptography has no support for X509 parsing at a level above its C bindings. That will eventually change, but PyOpenSSL has tools for this right now.
> 
> 
> On June 26, 2014 at 8:05:47 AM, Laurens Van Houtven (_ at webseducer.com) wrote:
> 
>> Hi Carlos, 
>> 
>> 
>> This sounds like a job for PyOpenSSL, which uses Cryptography internally. I think it has support for what you need, but even if there?s a bit missing, it probably makes a lot of sense to add it to PyOpenSSL, particularly since we hope to be releasing 0.15 soon. 
>> 
>> 
>> hth 
>> lvh 
>> _______________________________________________ 
>> Cryptography-dev mailing list 
>> Cryptography-dev at python.org 
>> https://mail.python.org/mailman/listinfo/cryptography-dev 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev


From glyph at twistedmatrix.com  Fri Jun 27 03:03:55 2014
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Thu, 26 Jun 2014 18:03:55 -0700
Subject: [Cryptography-dev] help: pica cryptography get subjectAltNames
In-Reply-To: <687A9EFF-B892-4B7D-AFDF-B0B6083D5BC4@rackspace.com>
References: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>
 <0D41D9CE-DA70-43E9-ACA3-043CAC2A4C5B@lvh.cc>
 <etPan.53ac2b19.238e1f29.8543@atlas.local>
 <687A9EFF-B892-4B7D-AFDF-B0B6083D5BC4@rackspace.com>
Message-ID: <718CEED8-B837-4608-A963-A719E26B30E1@twistedmatrix.com>

Does pyOpenSSL have this functionality built in?  My understanding is that it doesn't, which is why <https://pypi.python.org/pypi/service_identity> uses pyasn1 for ASN.1 extension parsing.  (By the way, you probably just want to use the service_identity module unless you're doing something truly unusual with SANs ;-)).

-glyph

On Jun 26, 2014, at 12:59 PM, Carlos Garza <carlos.garza at rackspace.com> wrote:

>   That works out great for me. I didn't know if I had time right now to add functionality
> to the cryptography project but I have a deadline. My first choice was to use pyasn1 and I already
> have written utile to extract the altNames but I'll consider PyOpenSSL as I'm more mature
> by now then when I first used it back in the python 2.4 days.
> 
>    Paul let me know when and how I can contribute to the hazmat code. It looks like a wonderful
> project that I want to contribute out side of my work obligations. I'm impressed by the mathematics
> behind it. Please advise me on when and how I can contribute. 
> 
> On Jun 26, 2014, at 9:15 AM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
> 
>> As lvh says, PyOpenSSL is the right tool for the job at this time. cryptography has no support for X509 parsing at a level above its C bindings. That will eventually change, but PyOpenSSL has tools for this right now.
>> 
>> 
>> On June 26, 2014 at 8:05:47 AM, Laurens Van Houtven (_ at webseducer.com) wrote:
>> 
>>> Hi Carlos, 
>>> 
>>> 
>>> This sounds like a job for PyOpenSSL, which uses Cryptography internally. I think it has support for what you need, but even if there?s a bit missing, it probably makes a lot of sense to add it to PyOpenSSL, particularly since we hope to be releasing 0.15 soon. 
>>> 
>>> 
>>> hth 
>>> lvh 
>>> _______________________________________________ 
>>> Cryptography-dev mailing list 
>>> Cryptography-dev at python.org 
>>> https://mail.python.org/mailman/listinfo/cryptography-dev 
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
> 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140626/24b3e4da/attachment.html>

From carlos.garza at rackspace.com  Fri Jun 27 05:56:34 2014
From: carlos.garza at rackspace.com (Carlos Garza)
Date: Fri, 27 Jun 2014 03:56:34 +0000
Subject: [Cryptography-dev] help: pica cryptography get subjectAltNames
In-Reply-To: <718CEED8-B837-4608-A963-A719E26B30E1@twistedmatrix.com>
References: <8EC5D8FD-A841-48D3-93B1-D2FC3790DF07@rackspace.com>
 <0D41D9CE-DA70-43E9-ACA3-043CAC2A4C5B@lvh.cc>
 <etPan.53ac2b19.238e1f29.8543@atlas.local>
 <687A9EFF-B892-4B7D-AFDF-B0B6083D5BC4@rackspace.com>
 <718CEED8-B837-4608-A963-A719E26B30E1@twistedmatrix.com>
Message-ID: <F1E68344-D72E-42C6-AAB5-76745B785889@rackspace.com>

    I ended up just setting my asn1Spec to Classes in pyasn1_modules.rfc2459
in my decoder.decode invocations. Seems to work for me. The pyOpenSSL stuff seems
to have a way to grab the extensions as a list from an X509 but I would still have
to revert to pyasn1 to decode the general names etc so I figured just
use the pyasn1 module directly instead of mixing calls.

On Jun 26, 2014, at 8:03 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>
 wrote:

> Does pyOpenSSL have this functionality built in?  My understanding is that it doesn't, which is why <https://pypi.python.org/pypi/service_identity> uses pyasn1 for ASN.1 extension parsing.  (By the way, you probably just want to use the service_identity module unless you're doing something truly unusual with SANs ;-)).
> 
> -glyph
> 
> On Jun 26, 2014, at 12:59 PM, Carlos Garza <carlos.garza at rackspace.com> wrote:
> 
>>   That works out great for me. I didn't know if I had time right now to add functionality
>> to the cryptography project but I have a deadline. My first choice was to use pyasn1 and I already
>> have written utile to extract the altNames but I'll consider PyOpenSSL as I'm more mature
>> by now then when I first used it back in the python 2.4 days.
>> 
>>    Paul let me know when and how I can contribute to the hazmat code. It looks like a wonderful
>> project that I want to contribute out side of my work obligations. I'm impressed by the mathematics
>> behind it. Please advise me on when and how I can contribute. 
>> 
>> On Jun 26, 2014, at 9:15 AM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
>> 
>>> As lvh says, PyOpenSSL is the right tool for the job at this time. cryptography has no support for X509 parsing at a level above its C bindings. That will eventually change, but PyOpenSSL has tools for this right now.
>>> 
>>> 
>>> On June 26, 2014 at 8:05:47 AM, Laurens Van Houtven (_ at webseducer.com) wrote:
>>> 
>>>> Hi Carlos, 
>>>> 
>>>> 
>>>> This sounds like a job for PyOpenSSL, which uses Cryptography internally. I think it has support for what you need, but even if there?s a bit missing, it probably makes a lot of sense to add it to PyOpenSSL, particularly since we hope to be releasing 0.15 soon. 
>>>> 
>>>> 
>>>> hth 
>>>> lvh 
>>>> _______________________________________________ 
>>>> Cryptography-dev mailing list 
>>>> Cryptography-dev at python.org 
>>>> https://mail.python.org/mailman/listinfo/cryptography-dev 
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>> 
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
> 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev


From paul.l.kehrer at gmail.com  Sat Jun 28 04:47:34 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 27 Jun 2014 20:47:34 -0600
Subject: [Cryptography-dev] PyCA cryptography 0.5 release criteria
Message-ID: <etPan.53ae2cc6.511ea54b.8543@atlas>

I?m pleased to say that we?ll soon be able to close the final issues that are currently tagged for 0.5. (https://github.com/pyca/cryptography/issues?milestone=5&state=open) If there are any issues you think we should consider a blocker please let me know!

This upcoming release significantly changes the API for asymmetric operations with RSA and DSA, as well as adding major new features like EC support, CFB8 mode, HKDFExpand, AES CTR mode on OpenSSL 0.9.8, some early asymmetric key serialization support, and the usual smorgasbord of code and testing improvements.

One item that still needs some attention is...

Include OpenSSL in our Windows wheels (https://github.com/pyca/cryptography/issues/1121)

The consensus in the issue (thus far) appears to be that we should statically link OpenSSL in our Windows wheels. This would greatly improve the user experience for Windows users at the cost of additional administrative overhead (new releases when OpenSSL does a release, security advisories for OpenSSL vulnerabilities in versions we have linked). Please weigh in with your thoughts!

Thanks to everyone for their help so far this release cycle. This project would not exist without you.

-Paul


1. The previous API, in accordance with our stated deprecation policy (https://cryptography.io/en/latest/api-stability/#deprecation) will continue to work, but emit deprecation warnings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140627/f9e4fa0a/attachment.html>

From alex.gaynor at gmail.com  Mon Jun 30 18:29:04 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 30 Jun 2014 09:29:04 -0700
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
Message-ID: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>

Background:

Right now when you provide a tag to GCM for decryption/verification, we
allow it to be truncated, always. This means that applications that don't
want truncation must add their own length checking.

Analysis:

This is terrible, because it means most applications will silently allow
truncation down to a 4-byte MAC (32-bits), which is much easier to brute
force to otherwise exploit than the full 16-byte MAC.

Proposal:

Changing the constructor to disallow truncated MACs by default, and require
the user to explicitly opt in to truncation.

This is technically backwards-incompatible, but I think it's a good change,
because of the enormity of the improvement in security.

A patch doing this is here: https://github.com/pyca/cryptography/pull/1201

Feedback please!
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/63e45c72/attachment.html>

From _ at lvh.io  Mon Jun 30 19:12:37 2014
From: _ at lvh.io (Laurens Van Houtven)
Date: Mon, 30 Jun 2014 19:12:37 +0200
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
Message-ID: <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>

Yes, yes, a thousand times yes!

Keep in mind that if you truncate a GCM tag at all, let's say down to your
32 bit example, the security level for existential forgery is much lower
than 32 bits. Furthermore, successful forgeries may reveal the
authentication key. [Ferguson05]

[Ferguson05]:
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf


On Mon, Jun 30, 2014 at 6:29 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Background:
>
> Right now when you provide a tag to GCM for decryption/verification, we
> allow it to be truncated, always. This means that applications that don't
> want truncation must add their own length checking.
>
> Analysis:
>
> This is terrible, because it means most applications will silently allow
> truncation down to a 4-byte MAC (32-bits), which is much easier to brute
> force to otherwise exploit than the full 16-byte MAC.
>
> Proposal:
>
> Changing the constructor to disallow truncated MACs by default, and
> require the user to explicitly opt in to truncation.
>
> This is technically backwards-incompatible, but I think it's a good
> change, because of the enormity of the improvement in security.
>
> A patch doing this is here: https://github.com/pyca/cryptography/pull/1201
>
> Feedback please!
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/ea14a10d/attachment.html>

From alexs at prol.etari.at  Mon Jun 30 19:41:58 2014
From: alexs at prol.etari.at (Alex Stapleton)
Date: Mon, 30 Jun 2014 18:41:58 +0100
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
Message-ID: <146eddb80a0.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at>

+1. Nice find.


On 30 June 2014 17:29:19 Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Background:
>
> Right now when you provide a tag to GCM for decryption/verification, we
> allow it to be truncated, always. This means that applications that don't
> want truncation must add their own length checking.
>
> Analysis:
>
> This is terrible, because it means most applications will silently allow
> truncation down to a 4-byte MAC (32-bits), which is much easier to brute
> force to otherwise exploit than the full 16-byte MAC.
>
> Proposal:
>
> Changing the constructor to disallow truncated MACs by default, and require
> the user to explicitly opt in to truncation.
>
> This is technically backwards-incompatible, but I think it's a good change,
> because of the enormity of the improvement in security.
>
> A patch doing this is here: https://github.com/pyca/cryptography/pull/1201
>
> Feedback please!
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
>
>
> ----------
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/92d72e84/attachment.html>

From glyph at twistedmatrix.com  Mon Jun 30 20:20:12 2014
From: glyph at twistedmatrix.com (Glyph)
Date: Mon, 30 Jun 2014 11:20:12 -0700
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
 <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
Message-ID: <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>

On Jun 30, 2014, at 10:12 AM, Laurens Van Houtven <_ at lvh.io> wrote:

> Yes, yes, a thousand times yes!
> 
> Keep in mind that if you truncate a GCM tag at all, let's say down to your 32 bit example, the security level for existential forgery is much lower than 32 bits. Furthermore, successful forgeries may reveal the authentication key. [Ferguson05]

I don't entirely understand the attack here, but this sounds very much to me like truncation should simply be disabled, not opt-in.

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/6d4bfbad/attachment-0001.html>

From paul.l.kehrer at gmail.com  Mon Jun 30 20:29:35 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Mon, 30 Jun 2014 12:29:35 -0600
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
 <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
 <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>
Message-ID: <etPan.53b1ac8f.6b8b4567.35a@atlas>

If we entirely disable truncation we have a significant set of NIST vectors we can?t run tests against. It might be worth it though. I?ve never heard a good case for truncation outside of ?well NIST allows it?.


On June 30, 2014 at 12:27:32 PM, Glyph (glyph at twistedmatrix.com) wrote:

On Jun 30, 2014, at 10:12 AM, Laurens Van Houtven <_ at lvh.io> wrote:

Yes, yes, a thousand times yes!

Keep in mind that if you truncate a GCM tag at all, let's say down to your 32 bit example, the security level for existential forgery is much lower than 32 bits. Furthermore, successful forgeries may reveal the authentication key. [Ferguson05]

I don't entirely understand the attack here, but this sounds very much to me like truncation should simply be disabled, not opt-in.

-glyph
_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/375cabe1/attachment.html>

From glyph at twistedmatrix.com  Mon Jun 30 20:32:57 2014
From: glyph at twistedmatrix.com (Glyph)
Date: Mon, 30 Jun 2014 11:32:57 -0700
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <etPan.53b1ac8f.6b8b4567.35a@atlas>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
 <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
 <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>
 <etPan.53b1ac8f.6b8b4567.35a@atlas>
Message-ID: <8FB55BDC-4BDF-4AEB-99B3-00FD094CAF43@twistedmatrix.com>


On Jun 30, 2014, at 11:29 AM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> If we entirely disable truncation we have a significant set of NIST vectors we can?t run tests against. It might be worth it though. I?ve never heard a good case for truncation outside of ?well NIST allows it?.

NIST has allowed some other stuff too though, I seem to remember seeing their name in the news a little while back.

-g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/343459d1/attachment.html>

From alex.gaynor at gmail.com  Mon Jun 30 20:33:09 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 30 Jun 2014 11:33:09 -0700
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <etPan.53b1ac8f.6b8b4567.35a@atlas>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
 <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
 <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>
 <etPan.53b1ac8f.6b8b4567.35a@atlas>
Message-ID: <CAFRnB2WHrXU58oz_KdVscDP61gCnoJ+=jsw7V2+FOWf-0N7ixQ@mail.gmail.com>

Yes. FWIW I think making truncation opt-in can be a first step to disabling
it entirely, with my patch there's now a clear place to apply deprecation
warnings (and I think we do need a deprecation cycle to completely remove
it).


On Mon, Jun 30, 2014 at 11:29 AM, Paul Kehrer <paul.l.kehrer at gmail.com>
wrote:

> If we entirely disable truncation we have a significant set of NIST
> vectors we can?t run tests against. It might be worth it though. I?ve never
> heard a good case for truncation outside of ?well NIST allows it?.
>
>
> On June 30, 2014 at 12:27:32 PM, Glyph (glyph at twistedmatrix.com) wrote:
>
> On Jun 30, 2014, at 10:12 AM, Laurens Van Houtven <_ at lvh.io> wrote:
>
>  Yes, yes, a thousand times yes!
>
>  Keep in mind that if you truncate a GCM tag at all, let's say down to
> your 32 bit example, the security level for existential forgery is much
> lower than 32 bits. Furthermore, successful forgeries may reveal the
> authentication key. [Ferguson05]
>
>
> I don't entirely understand the attack here, but this sounds very much to
> me like truncation should simply be disabled, not opt-in.
>
> -glyph
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/d56f60e8/attachment.html>

From _ at lvh.io  Mon Jun 30 22:35:00 2014
From: _ at lvh.io (Laurens Van Houtven)
Date: Mon, 30 Jun 2014 22:35:00 +0200
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <CAFRnB2WHrXU58oz_KdVscDP61gCnoJ+=jsw7V2+FOWf-0N7ixQ@mail.gmail.com>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
 <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
 <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>
 <etPan.53b1ac8f.6b8b4567.35a@atlas>
 <CAFRnB2WHrXU58oz_KdVscDP61gCnoJ+=jsw7V2+FOWf-0N7ixQ@mail.gmail.com>
Message-ID: <CAE_Hg6YPU+iNPARU3HFya-WrtiF4qEOoCJa1VpafLnh-Uj75wg@mail.gmail.com>

This is hazmat, right? Keep in mind that some protocols may insist on
truncated tags, and, as bad of an idea as that may be, it should be
supported (if actively discouraged and certainly something you have to very
consciously opt in to).


On Mon, Jun 30, 2014 at 8:33 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Yes. FWIW I think making truncation opt-in can be a first step to
> disabling it entirely, with my patch there's now a clear place to apply
> deprecation warnings (and I think we do need a deprecation cycle to
> completely remove it).
>
>
> On Mon, Jun 30, 2014 at 11:29 AM, Paul Kehrer <paul.l.kehrer at gmail.com>
> wrote:
>
>> If we entirely disable truncation we have a significant set of NIST
>> vectors we can?t run tests against. It might be worth it though. I?ve never
>> heard a good case for truncation outside of ?well NIST allows it?.
>>
>>
>> On June 30, 2014 at 12:27:32 PM, Glyph (glyph at twistedmatrix.com) wrote:
>>
>> On Jun 30, 2014, at 10:12 AM, Laurens Van Houtven <_ at lvh.io> wrote:
>>
>>  Yes, yes, a thousand times yes!
>>
>>  Keep in mind that if you truncate a GCM tag at all, let's say down to
>> your 32 bit example, the security level for existential forgery is much
>> lower than 32 bits. Furthermore, successful forgeries may reveal the
>> authentication key. [Ferguson05]
>>
>>
>> I don't entirely understand the attack here, but this sounds very much to
>> me like truncation should simply be disabled, not opt-in.
>>
>> -glyph
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/aa3c0ffd/attachment-0001.html>

From alexs at prol.etari.at  Mon Jun 30 23:06:53 2014
From: alexs at prol.etari.at (Alex Stapleton)
Date: Mon, 30 Jun 2014 22:06:53 +0100
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <CAFRnB2WHrXU58oz_KdVscDP61gCnoJ+=jsw7V2+FOWf-0N7ixQ@mail.gmail.com>
References: <CAFRnB2XuqyCyuvTY10qnqnmmsuHspG++k+JrND7_nM2UJBzS9w@mail.gmail.com>
 <CAE_Hg6YF7gzvumyyjEzOWg_DtHG78aNSRVbbxnkPr+R2_TXdXw@mail.gmail.com>
 <C302508D-3D7E-429F-AB83-452EDE229272@twistedmatrix.com>
 <etPan.53b1ac8f.6b8b4567.35a@atlas>
 <CAFRnB2WHrXU58oz_KdVscDP61gCnoJ+=jsw7V2+FOWf-0N7ixQ@mail.gmail.com>
Message-ID: <146ee99eea0.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at>

Do we know any GCM using applications that actually use this feature at 
all? Using sub 80 bit MACs hasn't been a good idea for quite a while so 
truncation doesn't seem terribly attractive. If anything 128 bits might 
seem a little small?


On 30 June 2014 19:33:23 Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Yes. FWIW I think making truncation opt-in can be a first step to disabling
> it entirely, with my patch there's now a clear place to apply deprecation
> warnings (and I think we do need a deprecation cycle to completely remove
> it).
>
>
> On Mon, Jun 30, 2014 at 11:29 AM, Paul Kehrer <paul.l.kehrer at gmail.com>
> wrote:
>
> > If we entirely disable truncation we have a significant set of NIST
> > vectors we can?t run tests against. It might be worth it though. I?ve never
> > heard a good case for truncation outside of ?well NIST allows it?.
> >
> >
> > On June 30, 2014 at 12:27:32 PM, Glyph (glyph at twistedmatrix.com) wrote:
> >
> > On Jun 30, 2014, at 10:12 AM, Laurens Van Houtven <_ at lvh.io> wrote:
> >
> >  Yes, yes, a thousand times yes!
> >
> >  Keep in mind that if you truncate a GCM tag at all, let's say down to
> > your 32 bit example, the security level for existential forgery is much
> > lower than 32 bits. Furthermore, successful forgeries may reveal the
> > authentication key. [Ferguson05]
> >
> >
> > I don't entirely understand the attack here, but this sounds very much to
> > me like truncation should simply be disabled, not opt-in.
> >
> > -glyph
> > _______________________________________________
> > Cryptography-dev mailing list
> > Cryptography-dev at python.org
> > https://mail.python.org/mailman/listinfo/cryptography-dev
> >
> >
> > _______________________________________________
> > Cryptography-dev mailing list
> > Cryptography-dev at python.org
> > https://mail.python.org/mailman/listinfo/cryptography-dev
> >
> >
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
>
>
> ----------
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/504ee693/attachment.html>