From jcea at jcea.es  Wed Nov 19 22:06:54 2014
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 19 Nov 2014 22:06:54 +0100
Subject: [Cryptography-dev] ping
Message-ID: <546D066E.6040903@jcea.es>

Anybody there?

-- 
Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

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

From jcea at jcea.es  Wed Nov 19 22:35:09 2014
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 19 Nov 2014 22:35:09 +0100
Subject: [Cryptography-dev] keys and signatures import/export
Message-ID: <546D0D0D.1020508@jcea.es>

I am working on a project that requires standar key and signatures data
formats. Ugly ASN.1 everywhere.

I wonder how is the serialization work going in "Crytography".

-- 
Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

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

From _ at lvh.io  Wed Nov 19 22:37:14 2014
From: _ at lvh.io (Laurens Van Houtven)
Date: Wed, 19 Nov 2014 22:37:14 +0100
Subject: [Cryptography-dev] ping
In-Reply-To: <546D066E.6040903@jcea.es>
References: <546D066E.6040903@jcea.es>
Message-ID: <5856F352-B95D-4EDB-8B51-09AA9E01318D@lvh.io>

On 19 Nov 2014, at 22:06, Jesus Cea <jcea at jcea.es> wrote:

> Anybody there?

No ;-)

-------------- 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/20141119/51a4fff9/attachment.sig>

From foibey at gmail.com  Thu Nov 20 02:07:13 2014
From: foibey at gmail.com (Phoebe Queen)
Date: Thu, 20 Nov 2014 01:07:13 +0000
Subject: [Cryptography-dev] ping
In-Reply-To: <5856F352-B95D-4EDB-8B51-09AA9E01318D@lvh.io>
References: <546D066E.6040903@jcea.es>
 <5856F352-B95D-4EDB-8B51-09AA9E01318D@lvh.io>
Message-ID: <CABM1FiCm7soWL9cVV8Uu5HPd2YGGoTGdArqcM-K8HrB+1maz3g@mail.gmail.com>

pong

On 19 November 2014 21:37, Laurens Van Houtven <_ at lvh.io> wrote:

> On 19 Nov 2014, at 22:06, Jesus Cea <jcea at jcea.es> wrote:
>
> > Anybody there?
>
> No ;-)
>
>
> _______________________________________________
> 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/20141120/08c840b4/attachment.html>

From paul.l.kehrer at gmail.com  Thu Nov 20 04:13:03 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Wed, 19 Nov 2014 17:13:03 -1000
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <546D0D0D.1020508@jcea.es>
References: <546D0D0D.1020508@jcea.es>
Message-ID: <etPan.546d5c3f.643c9869.1e5@atlas.local>

Thanks for your interest in the project!

We have full loading support for PEM encoded asymmetric keys (both traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release (probably in around 4 weeks) should add support for serialization back to disk. You can view the progress of that work here:?https://github.com/pyca/cryptography/pull/1390

-Paul Kehrer

On November 19, 2014 at 11:35:16 AM, Jesus Cea (jcea at jcea.es) wrote:

I am working on a project that requires standar key and signatures data  
formats. Ugly ASN.1 everywhere.  

I wonder how is the serialization work going in "Crytography".  

--  
Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/  
jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/  
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/  
jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/  
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/  
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/  
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz  

_______________________________________________  
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/20141119/d21c715a/attachment.html>

From alex.gaynor at gmail.com  Thu Nov 20 17:18:51 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Thu, 20 Nov 2014 16:18:51 +0000
Subject: [Cryptography-dev] The one where we talk about crypto-ethics
Message-ID: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>

Hi everybody,

Folks who've been following our issue tracker might have noticed I've been
working on a pure-python implementation of key loading, to replace the way
we use OpenSSL right now for that. Here's the motivation:

* The OpenSSL API provides absolutely no flexibility, there's no way to
control which encryption algorithms are used for encrypted keys -- this
means very old, very bad, algorithms are enabled by default and silently
work while providing you basically no protection.
* The OpenSSL APIs don't handle non-ascii passwords correctly -- I don't
know if this is a thing in practice (probably not, chicken and egg)
* The support key loading algorithms differs quite a bit from backend to
backend, this makes the API more consistent depending on which backend
you're using.


So that's the motivation. Before we even start reviewing the patches, I
think we need to ask ourselves about the ethical implications of writing
this stuff ourselves:

* Are we qualified to do this? Some of this code, for example the PKCS#12
KDF is straight up crypto. Other parts of it are more-or-less just parsing
and ASN.1 handling
* Parsing and ASN.1 handling still have serious security implications
* Are we qualified to review this code?
* On the flip side, we're moving a bunch of code from dangerous C to memory
safe Python.
* We actually write tests, which is probably not true of all of our
backends.

Computationally ethicists, please opine,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/fd62dfba/attachment.html>

From stefan.pochmann at gmail.com  Thu Nov 20 16:27:36 2014
From: stefan.pochmann at gmail.com (Stefan Pochmann)
Date: Thu, 20 Nov 2014 16:27:36 +0100
Subject: [Cryptography-dev] Recipe for files?
Message-ID: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>

I like the Fernet recipe, but I'd like a better recipe for files. One that
doesn't want the entire message at once (bad for big files) and that
doesn't bloat with base64. Should I do it myself with "hazardous materials"
(I might adapt the Fernet code) or will you maybe add such a recipe soon?

Something like this maybe:

f = SomethingLikeFernetButForFiles(key)
for block in f.encrypt(filename, blocksize):
    myhandling(block)

Or with a handler parameter:

f = SomethingLikeFernetButForFiles(key)
f.encrypt(filename, blocksize, myhandling)

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/7ce37526/attachment.html>

From mcepl at cepl.eu  Thu Nov 20 17:40:36 2014
From: mcepl at cepl.eu (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 20 Nov 2014 17:40:36 +0100
Subject: [Cryptography-dev] gmane?
Message-ID: <546E1984.4040206@cepl.eu>

Would it be possible to add this email list to Gmane? I know there is
unfortunately named http://dir.gmane.org/gmane.comp.python.cryptography
(which is actually PyCrypto), but could some good solution be found?

Best,

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

A child can go only so far in life without potty training.  It
is not mere coincidence that six of the last seven presidents
were potty trained, not to mention nearly half of the nation's
state legislators.
        -- Dave Barry

From mcepl at cepl.eu  Thu Nov 20 17:31:40 2014
From: mcepl at cepl.eu (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 20 Nov 2014 17:31:40 +0100
Subject: [Cryptography-dev] The one where we talk about crypto-ethics
In-Reply-To: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>
References: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>
Message-ID: <546E176C.6010608@cepl.eu>

On 20/11/14 17:18, Alex Gaynor wrote:
> * Are we qualified to do this? Some of this code, for example the PKCS#12
> KDF is straight up crypto. Other parts of it are more-or-less just parsing
> and ASN.1 handling
> * Parsing and ASN.1 handling still have serious security implications
> * Are we qualified to review this code?
> * On the flip side, we're moving a bunch of code from dangerous C to memory
> safe Python.
> * We actually write tests, which is probably not true of all of our
> backends.

My paranoid heart tells me this is wrong. Problems should be fixed in
the place where they should be fixed. It looks to me that if there is
something wrong with OpenSSL treating keys, then OpenSSL should be fixed.

Best,

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

In the government of this Commonwealth, the legislative
department shall never exercise the executive and judicial
powers, or either of them: The executive shall never exercise the
legislative and judicial powers, or either of them: The judicial
shall never exercise the legislative and executive powers, or
either of them: to the end it may be a government of laws and not
of men.
    -- John Adams in the Article XXXth of the Constitution of the
       Commonwealth of Massachusetts

From paul.l.kehrer at gmail.com  Thu Nov 20 18:11:06 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 20 Nov 2014 07:11:06 -1000
Subject: [Cryptography-dev] Recipe for files?
In-Reply-To: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>
References: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>
Message-ID: <etPan.546e20aa.2ae8944a.1e5@atlas.local>

Stefan,

We?ve talked in the past about a recipe for file encryption. The general consensus has been that the project would prefer to implement an existing spec rather than creating one so for now I?m afraid creating your own is probably the ?best? path unless you?re familiar with a standardized format that does this?

If you do choose to implement your own I?d suggest implementing it on top of Fernet using a frame* size that you consider to be a good trade off between ciphertext length per frame and the size of the HMAC. Ideally a spec similar to?https://github.com/fernet/spec could come out of it.

-Paul Kehrer

* I?ve been using frame when talking about this type of encryption to avoid confusing it with the native block size of a block cipher, but record (like a TLS record) would be equally descriptive.
On November 20, 2014 at 6:27:07 AM, Stefan Pochmann (stefan.pochmann at gmail.com) wrote:

I like the Fernet recipe, but I'd like a better recipe for files. One that doesn't want the entire message at once (bad for big files) and that doesn't bloat with base64. Should I do it myself with "hazardous materials" (I might adapt the Fernet code) or will you maybe add such a recipe soon?

Something like this maybe:

f = SomethingLikeFernetButForFiles(key)
for block in f.encrypt(filename, blocksize):
? ? myhandling(block)

Or with a handler parameter:

f = SomethingLikeFernetButForFiles(key)
f.encrypt(filename, blocksize, myhandling)

Stefan
_______________________________________________  
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/20141120/d881fb4e/attachment-0001.html>

From alex.gaynor at gmail.com  Thu Nov 20 18:13:53 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Thu, 20 Nov 2014 17:13:53 +0000
Subject: [Cryptography-dev] Recipe for files?
References: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>
 <etPan.546e20aa.2ae8944a.1e5@atlas.local>
Message-ID: <CAFRnB2UzAsF63avwye1fm5gVa4v9Pnp63onUj4+-uf6c9TQMTg@mail.gmail.com>

One thing to think about is making sure your scheme isn't vulnerable to
truncation attacks.

Alex

On Thu Nov 20 2014 at 9:11:23 AM Paul Kehrer <paul.l.kehrer at gmail.com>
wrote:

> Stefan,
>
> We?ve talked in the past about a recipe for file encryption. The general
> consensus has been that the project would prefer to implement an existing
> spec rather than creating one so for now I?m afraid creating your own is
> probably the ?best? path unless you?re familiar with a standardized format
> that does this?
>
> If you do choose to implement your own I?d suggest implementing it on top
> of Fernet using a frame* size that you consider to be a good trade off
> between ciphertext length per frame and the size of the HMAC. Ideally a
> spec similar to https://github.com/fernet/spec could come out of it.
>
> -Paul Kehrer
>
> * I?ve been using frame when talking about this type of encryption to
> avoid confusing it with the native block size of a block cipher, but record
> (like a TLS record) would be equally descriptive.
>
> On November 20, 2014 at 6:27:07 AM, Stefan Pochmann (
> stefan.pochmann at gmail.com) wrote:
>
> I like the Fernet recipe, but I'd like a better recipe for files. One that
> doesn't want the entire message at once (bad for big files) and that
> doesn't bloat with base64. Should I do it myself with "hazardous materials"
> (I might adapt the Fernet code) or will you maybe add such a recipe soon?
>
> Something like this maybe:
>
>  f = SomethingLikeFernetButForFiles(key)
> for block in f.encrypt(filename, blocksize):
>     myhandling(block)
>
> Or with a handler parameter:
>
> f = SomethingLikeFernetButForFiles(key)
> f.encrypt(filename, blocksize, myhandling)
>
> Stefan
>  _______________________________________________
> 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/20141120/b45bbbc4/attachment.html>

From paul.l.kehrer at gmail.com  Thu Nov 20 18:19:53 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 20 Nov 2014 07:19:53 -1000
Subject: [Cryptography-dev] gmane?
In-Reply-To: <546E1984.4040206@cepl.eu>
References: <546E1984.4040206@cepl.eu>
Message-ID: <etPan.546e22b9.238e1f29.1e5@atlas.local>

I have no objection to adding the list to gmane. We could do gmane.comp.python.pyca.cryptography (which would also let us have other mailing lists for projects under the PyCA banner in the future).

Mat?j, out of curiosity is there any specific reason you?d like us archived there?

-Paul
On November 20, 2014 at 7:03:23 AM, Mat?j Cepl (mcepl at cepl.eu) wrote:

Would it be possible to add this email list to Gmane? I know there is
unfortunately named http://dir.gmane.org/gmane.comp.python.cryptography
(which is actually PyCrypto), but could some good solution be found?

Best,

Mat?j
--  
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

A child can go only so far in life without potty training. It
is not mere coincidence that six of the last seven presidents
were potty trained, not to mention nearly half of the nation's
state legislators.
-- Dave Barry
_______________________________________________
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/20141120/63b7f030/attachment.html>

From dreid at dreid.org  Thu Nov 20 18:21:16 2014
From: dreid at dreid.org (David Reid)
Date: Thu, 20 Nov 2014 09:21:16 -0800
Subject: [Cryptography-dev] Recipe for files?
In-Reply-To: <CAFRnB2UzAsF63avwye1fm5gVa4v9Pnp63onUj4+-uf6c9TQMTg@mail.gmail.com>
References: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>
 <etPan.546e20aa.2ae8944a.1e5@atlas.local>
 <CAFRnB2UzAsF63avwye1fm5gVa4v9Pnp63onUj4+-uf6c9TQMTg@mail.gmail.com>
Message-ID: <CA+t4paxQWPcQkpHDwr+U3KOnHxQf2Cn9gxG33kHNV_mVKro08w@mail.gmail.com>

Unrelated to PyCA there is at least one implementation of miniLock
<https://github.com/kaepora/miniLock/blob/master/README.md> written in
Python called deadlock <https://pypi.python.org/pypi/deadlock>, but it is
unfortunately AGPLv3.

-David


On Thu, Nov 20, 2014 at 9:13 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> One thing to think about is making sure your scheme isn't vulnerable to
> truncation attacks.
>
> Alex
>
> On Thu Nov 20 2014 at 9:11:23 AM Paul Kehrer <paul.l.kehrer at gmail.com>
> wrote:
>
>> Stefan,
>>
>> We?ve talked in the past about a recipe for file encryption. The general
>> consensus has been that the project would prefer to implement an existing
>> spec rather than creating one so for now I?m afraid creating your own is
>> probably the ?best? path unless you?re familiar with a standardized format
>> that does this?
>>
>> If you do choose to implement your own I?d suggest implementing it on top
>> of Fernet using a frame* size that you consider to be a good trade off
>> between ciphertext length per frame and the size of the HMAC. Ideally a
>> spec similar to https://github.com/fernet/spec could come out of it.
>>
>> -Paul Kehrer
>>
>> * I?ve been using frame when talking about this type of encryption to
>> avoid confusing it with the native block size of a block cipher, but record
>> (like a TLS record) would be equally descriptive.
>>
>> On November 20, 2014 at 6:27:07 AM, Stefan Pochmann (
>> stefan.pochmann at gmail.com) wrote:
>>
>> I like the Fernet recipe, but I'd like a better recipe for files. One
>> that doesn't want the entire message at once (bad for big files) and that
>> doesn't bloat with base64. Should I do it myself with "hazardous materials"
>> (I might adapt the Fernet code) or will you maybe add such a recipe soon?
>>
>> Something like this maybe:
>>
>>  f = SomethingLikeFernetButForFiles(key)
>> for block in f.encrypt(filename, blocksize):
>>     myhandling(block)
>>
>> Or with a handler parameter:
>>
>> f = SomethingLikeFernetButForFiles(key)
>> f.encrypt(filename, blocksize, myhandling)
>>
>> Stefan
>>  _______________________________________________
>> 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/20141120/36c17fa5/attachment-0001.html>

From glyph at twistedmatrix.com  Thu Nov 20 18:34:22 2014
From: glyph at twistedmatrix.com (Glyph)
Date: Thu, 20 Nov 2014 18:34:22 +0100
Subject: [Cryptography-dev] it's actually about ethics in key derivation
In-Reply-To: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>
References: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>
Message-ID: <1F775D72-DA94-4870-8E8E-44493BA00E54@twistedmatrix.com>


> On Nov 20, 2014, at 17:18, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> So that's the motivation. Before we even start reviewing the patches, I think we need to ask ourselves about the ethical implications of writing this stuff ourselves:
> 
> * Are we qualified to do this? Some of this code, for example the PKCS#12 KDF is straight up crypto. Other parts of it are more-or-less just parsing and ASN.1 handling
> * Are we qualified to review this code?

There is no currently broadly-accepted legal, moral, or social standard for who is qualified to do this kind of thing and who isn't.  My feeling is that attempting to divide the world up according to some argument from authority into people who are "qualified" and "unqualified" is at best a waste of time and itself deeply deceptive and possibly harmful.

For example, despite OpenSSL's hilarious litany of failures, I think it's clear that we'd all be worse off if, in the face of disclosures about global state-sponsored surveillance, we had no free software with which to do widespread transport layer security, and instead had to wait for a committee of graybeard authority figures with PhDs to tell someone they're allowed to implement something.  (That's not to say that everything about OpenSSL's development has been free from ethical lapses.  There are obviously failures on that front, too.  But it's very much better than nothing.)

The question is really whether creating such software according to our collective skill and experience is potentially misleading to the public: would it be advertising a security property it does not in fact have?  The primary ethical lapse to be concerned with here is deception.  That deception might be indirect; it might be unintentional.  So some level of care is warranted.

I think that the way to address this is not to avoid implementing things, but to have a clear audit trail of who has looked at the code involved in any particular crypto implementation, whether they believe it works, and whether there are any specific concerns which might be addressed.  The simple boolean of "has this been audited" has been shown to be not terribly effective either, so saying who has audited it, when, what remediations were applied, etc, will provide a clear idea of why we honestly believe that these implementations are effective, and provide a template for future reviewers to follow.

This sort of thing has to be made at least somewhat layperson-accessible though.  Just slapping some fine print on the bottom of the box does not address concerns about potentially fooling people through omission; the caveats and limitations need to be clearly and prominently displayed.

> * Parsing and ASN.1 handling still have serious security implications
> * On the flip side, we're moving a bunch of code from dangerous C to memory safe Python.

On the KDF side, where timing attacks are a concern, and there is the possibility for input-dependent branches, I would be maybe a little concerned.  If those more well-versed in cryptographic primitives on this list agree with this concern, this is exactly the sort of thing that should be documented: something that says "while we believe that, to the best of our ability, this KDF is safe to use, we have an unverified concern that using a high-level language to implement this functionality may open the door to a timing attack, and we would like verification that the steps we have taken to mitigate this are effective..."

But on the parsing-and-handling side, I am fairly confident that the second point here completely outweighs the first and this will be a big improvement all around.

> * We actually write tests, which is probably not true of all of our backends.


This is just one attribute of the process and the team working on cryptography.

-glyph


From glyph at twistedmatrix.com  Thu Nov 20 18:48:20 2014
From: glyph at twistedmatrix.com (Glyph)
Date: Thu, 20 Nov 2014 18:48:20 +0100
Subject: [Cryptography-dev] Recipe for files?
In-Reply-To: <CA+t4paxQWPcQkpHDwr+U3KOnHxQf2Cn9gxG33kHNV_mVKro08w@mail.gmail.com>
References: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>
 <etPan.546e20aa.2ae8944a.1e5@atlas.local>
 <CAFRnB2UzAsF63avwye1fm5gVa4v9Pnp63onUj4+-uf6c9TQMTg@mail.gmail.com>
 <CA+t4paxQWPcQkpHDwr+U3KOnHxQf2Cn9gxG33kHNV_mVKro08w@mail.gmail.com>
Message-ID: <1DFA0EF1-EA2B-4EE0-9CBA-50D2E1089DAE@twistedmatrix.com>

Equally unfortunate:

NotImplementedError: deadlock is Python 3 only, and is only known to run on 3.2 or above.

-g

> On Nov 20, 2014, at 18:21, David Reid <dreid at dreid.org> wrote:
> 
> Unrelated to PyCA there is at least one implementation of miniLock <https://github.com/kaepora/miniLock/blob/master/README.md> written in Python called deadlock <https://pypi.python.org/pypi/deadlock>, but it is unfortunately AGPLv3.
> 
> -David
> 
> 
> On Thu, Nov 20, 2014 at 9:13 AM, Alex Gaynor <alex.gaynor at gmail.com <mailto:alex.gaynor at gmail.com>> wrote:
> One thing to think about is making sure your scheme isn't vulnerable to truncation attacks.
> 
> Alex
> 
> On Thu Nov 20 2014 at 9:11:23 AM Paul Kehrer <paul.l.kehrer at gmail.com <mailto:paul.l.kehrer at gmail.com>> wrote:
> Stefan,
> 
> We?ve talked in the past about a recipe for file encryption. The general consensus has been that the project would prefer to implement an existing spec rather than creating one so for now I?m afraid creating your own is probably the ?best? path unless you?re familiar with a standardized format that does this?
> 
> If you do choose to implement your own I?d suggest implementing it on top of Fernet using a frame* size that you consider to be a good trade off between ciphertext length per frame and the size of the HMAC. Ideally a spec similar to https://github.com/fernet/spec <https://github.com/fernet/spec> could come out of it.
> 
> -Paul Kehrer
> 
> * I?ve been using frame when talking about this type of encryption to avoid confusing it with the native block size of a block cipher, but record (like a TLS record) would be equally descriptive.
> 
> On November 20, 2014 at 6:27:07 AM, Stefan Pochmann (stefan.pochmann at gmail.com <mailto:stefan.pochmann at gmail.com>) wrote:
> 
>> I like the Fernet recipe, but I'd like a better recipe for files. One that doesn't want the entire message at once (bad for big files) and that doesn't bloat with base64. Should I do it myself with "hazardous materials" (I might adapt the Fernet code) or will you maybe add such a recipe soon?
>> 
>> Something like this maybe:
>> 
>> f = SomethingLikeFernetButForFiles(key)
>> for block in f.encrypt(filename, blocksize):
>>     myhandling(block)
>> 
>> Or with a handler parameter:
>> 
>> f = SomethingLikeFernetButForFiles(key)
>> f.encrypt(filename, blocksize, myhandling)
>> 
>> Stefan
>> _______________________________________________ 
>> Cryptography-dev mailing list 
>> Cryptography-dev at python.org <mailto:Cryptography-dev at python.org> 
>> https://mail.python.org/mailman/listinfo/cryptography-dev <https://mail.python.org/mailman/listinfo/cryptography-dev> 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org <mailto:Cryptography-dev at python.org>
> https://mail.python.org/mailman/listinfo/cryptography-dev <https://mail.python.org/mailman/listinfo/cryptography-dev>
> 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org <mailto:Cryptography-dev at python.org>
> https://mail.python.org/mailman/listinfo/cryptography-dev <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/20141120/f7d52e8a/attachment.html>

From mcepl at redhat.com  Thu Nov 20 17:40:03 2014
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 20 Nov 2014 17:40:03 +0100
Subject: [Cryptography-dev] gmane?
Message-ID: <546E1963.1090109@redhat.com>

Would it be possible to add this email list to Gmane? I know there is
unfortunately named http://dir.gmane.org/gmane.comp.python.cryptography
(which is actually PyCrypto), but could some good solution be found?

Best,

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

A child can go only so far in life without potty training.  It
is not mere coincidence that six of the last seven presidents
were potty trained, not to mention nearly half of the nation's
state legislators.
        -- Dave Barry

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

From mcepl at redhat.com  Thu Nov 20 19:03:58 2014
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 20 Nov 2014 19:03:58 +0100
Subject: [Cryptography-dev] gmane?
In-Reply-To: <etPan.546e22b9.238e1f29.1e5@atlas.local>
References: <546E1984.4040206@cepl.eu>
 <etPan.546e22b9.238e1f29.1e5@atlas.local>
Message-ID: <546E2D0E.8010105@redhat.com>

On 20/11/14 18:19, Paul Kehrer wrote:
> Mat?j, out of curiosity is there any specific reason you?d like us archived there?

I way prefer reading newsgroups via leafnode+slrn to emails.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Q: Is vi an easy editor to learn, is it intuitive?
A: Yes, some of us think so. But most people think that we are
   crazy.
    -- vi FAQ

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

From stefan.pochmann at gmail.com  Thu Nov 20 22:02:12 2014
From: stefan.pochmann at gmail.com (Stefan Pochmann)
Date: Thu, 20 Nov 2014 22:02:12 +0100
Subject: [Cryptography-dev] Recipe for files?
In-Reply-To: <1DFA0EF1-EA2B-4EE0-9CBA-50D2E1089DAE@twistedmatrix.com>
References: <CAHpmzU4gQmdV2m-Mop2fCzXZVPLJ_gB7zNmFPt14A-waGBkvbw@mail.gmail.com>
 <etPan.546e20aa.2ae8944a.1e5@atlas.local>
 <CAFRnB2UzAsF63avwye1fm5gVa4v9Pnp63onUj4+-uf6c9TQMTg@mail.gmail.com>
 <CA+t4paxQWPcQkpHDwr+U3KOnHxQf2Cn9gxG33kHNV_mVKro08w@mail.gmail.com>
 <1DFA0EF1-EA2B-4EE0-9CBA-50D2E1089DAE@twistedmatrix.com>
Message-ID: <CAHpmzU5ChXSJmvtEaKg2Y9_QQHOc1X_r_ntGSjJJrvBxbJbgcw@mail.gmail.com>

Thanks everyone. I already considered using Fernet on file chunks, so I'm
glad to see that suggested. And yes, I love the Fernet spec (both content
and presentation) and I'll look into miniLock now.

My use case btw is encrypted cloud backup (for all my files). Everybody
seems to use their own formats and not describe them well and I couldn't
find a standard format, so I decided to try writing my own spec+tool. If I
succeed, I'll publish it and the spec shall be as nice as Fernet's. (I'm
under no illusion that it'll catch on, but I think it'll at least be fun
and useful for myself.)

Stefan


On Thu, Nov 20, 2014 at 6:48 PM, Glyph <glyph at twistedmatrix.com> wrote:

> Equally unfortunate:
>
> NotImplementedError: deadlock is Python 3 only, and is only known to run
> on 3.2 or above.
>
> -g
>
> On Nov 20, 2014, at 18:21, David Reid <dreid at dreid.org> wrote:
>
> Unrelated to PyCA there is at least one implementation of miniLock
> <https://github.com/kaepora/miniLock/blob/master/README.md> written in
> Python called deadlock <https://pypi.python.org/pypi/deadlock>, but it is
> unfortunately AGPLv3.
>
> -David
>
>
> On Thu, Nov 20, 2014 at 9:13 AM, Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
>
>> One thing to think about is making sure your scheme isn't vulnerable to
>> truncation attacks.
>>
>> Alex
>>
>> On Thu Nov 20 2014 at 9:11:23 AM Paul Kehrer <paul.l.kehrer at gmail.com>
>> wrote:
>>
>>> Stefan,
>>>
>>> We?ve talked in the past about a recipe for file encryption. The general
>>> consensus has been that the project would prefer to implement an existing
>>> spec rather than creating one so for now I?m afraid creating your own is
>>> probably the ?best? path unless you?re familiar with a standardized format
>>> that does this?
>>>
>>> If you do choose to implement your own I?d suggest implementing it on
>>> top of Fernet using a frame* size that you consider to be a good trade off
>>> between ciphertext length per frame and the size of the HMAC. Ideally a
>>> spec similar to https://github.com/fernet/spec could come out of it.
>>>
>>> -Paul Kehrer
>>>
>>> * I?ve been using frame when talking about this type of encryption to
>>> avoid confusing it with the native block size of a block cipher, but record
>>> (like a TLS record) would be equally descriptive.
>>>
>>> On November 20, 2014 at 6:27:07 AM, Stefan Pochmann (
>>> stefan.pochmann at gmail.com) wrote:
>>>
>>> I like the Fernet recipe, but I'd like a better recipe for files. One
>>> that doesn't want the entire message at once (bad for big files) and that
>>> doesn't bloat with base64. Should I do it myself with "hazardous materials"
>>> (I might adapt the Fernet code) or will you maybe add such a recipe soon?
>>>
>>> Something like this maybe:
>>>
>>>  f = SomethingLikeFernetButForFiles(key)
>>> for block in f.encrypt(filename, blocksize):
>>>     myhandling(block)
>>>
>>> Or with a handler parameter:
>>>
>>> f = SomethingLikeFernetButForFiles(key)
>>> f.encrypt(filename, blocksize, myhandling)
>>>
>>> Stefan
>>>  _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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/20141120/162f33fd/attachment.html>

From alex.gaynor at gmail.com  Thu Nov 20 23:52:19 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Thu, 20 Nov 2014 22:52:19 +0000
Subject: [Cryptography-dev] it's actually about ethics in key derivation
References: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>
 <1F775D72-DA94-4870-8E8E-44493BA00E54@twistedmatrix.com>
Message-ID: <CAFRnB2XSD8W__759fmPN5tZow+8FH272cDfV6cJHgOQ-37nuQA@mail.gmail.com>

One thing I didn't mention: my patch, at present, uses PyASN.1, which as
far as I know hasn't been audited, and increases the surface area of
security-sensitive code.

Alex

On Thu Nov 20 2014 at 9:34:34 AM Glyph <glyph at twistedmatrix.com> wrote:

>
> > On Nov 20, 2014, at 17:18, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>
> > So that's the motivation. Before we even start reviewing the patches, I
> think we need to ask ourselves about the ethical implications of writing
> this stuff ourselves:
> >
> > * Are we qualified to do this? Some of this code, for example the
> PKCS#12 KDF is straight up crypto. Other parts of it are more-or-less just
> parsing and ASN.1 handling
> > * Are we qualified to review this code?
>
> There is no currently broadly-accepted legal, moral, or social standard
> for who is qualified to do this kind of thing and who isn't.  My feeling is
> that attempting to divide the world up according to some argument from
> authority into people who are "qualified" and "unqualified" is at best a
> waste of time and itself deeply deceptive and possibly harmful.
>
> For example, despite OpenSSL's hilarious litany of failures, I think it's
> clear that we'd all be worse off if, in the face of disclosures about
> global state-sponsored surveillance, we had no free software with which to
> do widespread transport layer security, and instead had to wait for a
> committee of graybeard authority figures with PhDs to tell someone they're
> allowed to implement something.  (That's not to say that everything about
> OpenSSL's development has been free from ethical lapses.  There are
> obviously failures on that front, too.  But it's very much better than
> nothing.)
>
> The question is really whether creating such software according to our
> collective skill and experience is potentially misleading to the public:
> would it be advertising a security property it does not in fact have?  The
> primary ethical lapse to be concerned with here is deception.  That
> deception might be indirect; it might be unintentional.  So some level of
> care is warranted.
>
> I think that the way to address this is not to avoid implementing things,
> but to have a clear audit trail of who has looked at the code involved in
> any particular crypto implementation, whether they believe it works, and
> whether there are any specific concerns which might be addressed.  The
> simple boolean of "has this been audited" has been shown to be not terribly
> effective either, so saying who has audited it, when, what remediations
> were applied, etc, will provide a clear idea of why we honestly believe
> that these implementations are effective, and provide a template for future
> reviewers to follow.
>
> This sort of thing has to be made at least somewhat layperson-accessible
> though.  Just slapping some fine print on the bottom of the box does not
> address concerns about potentially fooling people through omission; the
> caveats and limitations need to be clearly and prominently displayed.
>
> > * Parsing and ASN.1 handling still have serious security implications
> > * On the flip side, we're moving a bunch of code from dangerous C to
> memory safe Python.
>
> On the KDF side, where timing attacks are a concern, and there is the
> possibility for input-dependent branches, I would be maybe a little
> concerned.  If those more well-versed in cryptographic primitives on this
> list agree with this concern, this is exactly the sort of thing that should
> be documented: something that says "while we believe that, to the best of
> our ability, this KDF is safe to use, we have an unverified concern that
> using a high-level language to implement this functionality may open the
> door to a timing attack, and we would like verification that the steps we
> have taken to mitigate this are effective..."
>
> But on the parsing-and-handling side, I am fairly confident that the
> second point here completely outweighs the first and this will be a big
> improvement all around.
>
> > * We actually write tests, which is probably not true of all of our
> backends.
>
>
> This is just one attribute of the process and the team working on
> cryptography.
>
> -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/20141120/d419c6b5/attachment-0001.html>

From bdpayne at acm.org  Fri Nov 21 00:00:10 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 20 Nov 2014 15:00:10 -0800
Subject: [Cryptography-dev] The one where we talk about crypto-ethics
In-Reply-To: <546E176C.6010608@cepl.eu>
References: <CAFRnB2X84_syrYxHO6XYZ_wHwKpSLiMV3H3rFgmJ=UQg4xMHwA@mail.gmail.com>
 <546E176C.6010608@cepl.eu>
Message-ID: <CAFpPvXA7JG2fUq5-Lbm1pHxokvtYPDs3U3yAjAL_gpxwgjLYQQ@mail.gmail.com>

Caveat: I'm more of a lurker than an active participant on this project, so
take my thoughts with the appropriate weight :-)


> My paranoid heart tells me this is wrong. Problems should be fixed in
> the place where they should be fixed. It looks to me that if there is
> something wrong with OpenSSL treating keys, then OpenSSL should be fixed.
>

I tend to agree with this.  If there are fundamental issues with OpenSSL,
then they should be fixed in OpenSSL.  If OpenSSL won't take the fixes,
then that's a nice motivation to add support for a new backend -- something
that would be broadly useful for this project anyway.

If all else fails, I would only advise going down this road iff you could
get buy in from some of the true experts in the field and convince them to
provide guidance and code audits on that work.  I think that there's a time
and place for training new cryptographic engineers.  Some of the people on
this project are clearly well versed in the field and I suspect could do an
excellent job here.  With the proper mentorship, this could be a good end
result.  But you are wise to tread carefully and cautiously.

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/6c6a8529/attachment.html>

From jcea at jcea.es  Fri Nov 21 00:50:28 2014
From: jcea at jcea.es (Jesus Cea)
Date: Fri, 21 Nov 2014 00:50:28 +0100
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <etPan.546d5c3f.643c9869.1e5@atlas.local>
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local>
Message-ID: <546E7E44.4080705@jcea.es>

On 20/11/14 04:13, Paul Kehrer wrote:
> Thanks for your interest in the project!

Thanks for replying! :).

> We have full loading support for PEM encoded asymmetric keys (both
> traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release
> (probably in around 4 weeks) should add support for serialization back
> to disk. You can view the progress of that work
> here: https://github.com/pyca/cryptography/pull/1390

Great!. What about digital signature serialization generated from RSA
and EC keys? :-).

-- 
Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

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

From mcepl at cepl.eu  Fri Nov 21 00:26:29 2014
From: mcepl at cepl.eu (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 21 Nov 2014 00:26:29 +0100
Subject: [Cryptography-dev] gmane?
In-Reply-To: <etPan.546e22b9.238e1f29.1e5@atlas.local>
References: <546E1984.4040206@cepl.eu>
 <etPan.546e22b9.238e1f29.1e5@atlas.local>
Message-ID: <546E78A5.2030103@cepl.eu>

On 20/11/14 18:19, Paul Kehrer wrote:
> Mat?j, out of curiosity is there any specific reason you?d like us archived there?

I way prefer reading newsgroups via leafnode+slrn to emails.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Q: Is vi an easy editor to learn, is it intuitive?
A: Yes, some of us think so. But most people think that we are
   crazy.
    -- vi FAQ

From alex.gaynor at gmail.com  Fri Nov 21 01:21:32 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 21 Nov 2014 00:21:32 +0000
Subject: [Cryptography-dev] keys and signatures import/export
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local>
 <546E7E44.4080705@jcea.es>
Message-ID: <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>

The signers/verifiers for RSA and EC keys both use the signature in it's
DER encoded format. Did you want to store/load that in a specific file
format?

Alex

On Thu Nov 20 2014 at 3:51:45 PM Jesus Cea <jcea at jcea.es> wrote:

> On 20/11/14 04:13, Paul Kehrer wrote:
> > Thanks for your interest in the project!
>
> Thanks for replying! :).
>
> > We have full loading support for PEM encoded asymmetric keys (both
> > traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release
> > (probably in around 4 weeks) should add support for serialization back
> > to disk. You can view the progress of that work
> > here: https://github.com/pyca/cryptography/pull/1390
>
> Great!. What about digital signature serialization generated from RSA
> and EC keys? :-).
>
> --
> Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
> jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
>
> _______________________________________________
> 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/20141121/768feefa/attachment.html>

From jcea at jcea.es  Fri Nov 21 01:51:56 2014
From: jcea at jcea.es (Jesus Cea)
Date: Fri, 21 Nov 2014 01:51:56 +0100
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local> <546E7E44.4080705@jcea.es>
 <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
Message-ID: <546E8CAC.1060904@jcea.es>

On 21/11/14 01:21, Alex Gaynor wrote:
> The signers/verifiers for RSA and EC keys both use the signature in it's
> DER encoded format. Did you want to store/load that in a specific file
> format?

If I can create and verify signatures valid on OpenSSL I would be
golden. Hummm. I think DER would work.

-- 
Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

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

From paul.l.kehrer at gmail.com  Fri Nov 21 02:53:00 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 20 Nov 2014 15:53:00 -1000
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <546E8CAC.1060904@jcea.es>
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local> <546E7E44.4080705@jcea.es>
 <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
 <546E8CAC.1060904@jcea.es>
Message-ID: <C03AD014-E595-46D2-9D23-97F1705775E7@gmail.com>

Our current release supports exactly that.


> On Nov 20, 2014, at 2:51 PM, Jesus Cea <jcea at jcea.es> wrote:
> 
>> On 21/11/14 01:21, Alex Gaynor wrote:
>> The signers/verifiers for RSA and EC keys both use the signature in it's
>> DER encoded format. Did you want to store/load that in a specific file
>> format?
> 
> If I can create and verify signatures valid on OpenSSL I would be
> golden. Hummm. I think DER would work.
> 
> -- 
> Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
> jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

From ronf at timeheart.net  Fri Nov 21 06:33:38 2014
From: ronf at timeheart.net (Ron Frederick)
Date: Thu, 20 Nov 2014 21:33:38 -0800
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local> <546E7E44.4080705@jcea.es>
 <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
Message-ID: <550F8A1B-F1F1-46A2-8003-4D5CB8D6424A@timeheart.net>

In the case of SSH, it would actually be useful to be able to get the raw ?r? and ?s? values generated when performing the DSA signing operation, as the signing operation performed in SSH (as defined in RFC 4253) for DSA keys requires sending the signature as follows:
   Signing and verifying using this key format is done according to the
   Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
   [FIPS-180-2].

   The resulting signature is encoded as follows:

      string    "ssh-dss"
      string    dss_signature_blob

   The value for 'dss_signature_blob' is encoded as a string containing
   r, followed by s (which are 160-bit integers, without lengths or
   padding, unsigned, and in network byte order).
So, to do this, the integer versions of ?r? and ?s? are needed. Today, to use PyCA, I need to call the finalize() on a DSA signer object and then run a DER decode on the returned string to get back these integers.

For RSA, SSH defines the signature message as:
   Signing and verifying using this key format is performed according to
   the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

   The resulting signature is encoded as follows:

      string    "ssh-rsa"
      string    rsa_signature_blob

   The value for 'rsa_signature_blob' is encoded as a string containing
   s (which is an integer, without lengths or padding, unsigned, and in
   network byte order).
In this case, I didn?t have to do any decoding of the value returned by PyCA?s RSA signer object, though, suggesting that PyCA is not returning a DER-encoded value. It?s returning the result of the RSASSA-PKCS1-V1_5-SIGN function defined in RFC 3447:
   RSASSA-PKCS1-V1_5-SIGN (K, M)

   Input:
   K        signer's RSA private key
   M        message to be signed, an octet string

   Output:
   S        signature, an octet string of length k, where k is the
            length in octets of the RSA modulus n
I was able to use this in the SSH protocol directly. This suggests that the RSA & DSA implementations are inconsistent, though, with only one of them DER encoding its result.

I haven?t actually implemented a version of EC signing based on PyCA yet, so I don?t know what is returned there. However, the ECDSA signature blob for ECDSA is defined as:

   Signatures are encoded as follows:

      string   "ecdsa-sha2-[identifier]"
      string   ecdsa_signature_blob

   The string [identifier] is the identifier of the elliptic curve
   domain parameters.  The format of this string is specified in
   Section 6.1 <http://tools.ietf.org/html/rfc5656#section-6.1>.  Information on the REQUIRED and RECOMMENDED sets of
   elliptic curve domain parameters for use with this algorithm can be
   found in Section 10 <http://tools.ietf.org/html/rfc5656#section-10>.

   The ecdsa_signature_blob value has the following specific encoding:

      mpint    r
      mpint    s

   The integers r and s are the output of the ECDSA algorithm.

   The width of the integer fields is determined by the curve being
   used.  Note that the integers r and s are integers modulo the order
   of the cryptographic subgroup, which may be larger than the size of
   the finite field.

So, once again the raw ?r? and ?s? integer values would be required from the signer object to be able to construct this packet.

Because of these differences, I think there could be value in having a signing primitive in PyCA that returned the raw values rather than returning encoded versions of the values. The exact set of values to return would vary depending on the algorithm, though. For DSA & ECDSA, this would be two integers (r & s), whereas for RSA the return value is already correct (an octet string version of the integer s).


> On Nov 20, 2014, at 4:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> 
> The signers/verifiers for RSA and EC keys both use the signature in it's DER encoded format. Did you want to store/load that in a specific file format?
> 
> Alex
> 
> On Thu Nov 20 2014 at 3:51:45 PM Jesus Cea <jcea at jcea.es <mailto:jcea at jcea.es>> wrote:
> On 20/11/14 04:13, Paul Kehrer wrote:
> > Thanks for your interest in the project!
> 
> Thanks for replying! :).
> 
> > We have full loading support for PEM encoded asymmetric keys (both
> > traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release
> > (probably in around 4 weeks) should add support for serialization back
> > to disk. You can view the progress of that work
> > here: https://github.com/pyca/cryptography/pull/1390 <https://github.com/pyca/cryptography/pull/1390>
> 
> Great!. What about digital signature serialization generated from RSA
> and EC keys? :-).
> 
> --
> Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es <mailto:jcea at jcea.es> - http://www.jcea.es/ <http://www.jcea.es/>     _/_/    _/_/  _/_/    _/_/  _/_/
> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
> jabber / xmpp:jcea at jabber.org <mailto:xmpp%3Ajcea at jabber.org>  _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-- 
Ron Frederick
ronf at timeheart.net



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

From paul.l.kehrer at gmail.com  Fri Nov 21 06:43:28 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Thu, 20 Nov 2014 19:43:28 -1000
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <550F8A1B-F1F1-46A2-8003-4D5CB8D6424A@timeheart.net>
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local> <546E7E44.4080705@jcea.es>
 <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
 <550F8A1B-F1F1-46A2-8003-4D5CB8D6424A@timeheart.net>
Message-ID: <etPan.546ed100.6b8b4567.16d@atlas.local>

We?ve got an issue filed to track adding support for (r, s) return on DSA/ECDSA (from your original email about this actually!): https://github.com/pyca/cryptography/issues/1285

I am in favor of adding this, but haven?t spent the time to implement my most recent comment on the issue. I may try to take a look at this soon so we can get it into the seventh release.

-Paul
On November 20, 2014 at 7:33:54 PM, Ron Frederick (ronf at timeheart.net) wrote:

In the case of SSH, it would actually be useful to be able to get the raw ?r? and ?s? values generated when performing the DSA signing operation, as the signing operation performed in SSH (as defined in RFC 4253) for DSA keys requires sending the signature as follows:
   Signing and verifying using this key format is done according to the
   Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
   [FIPS-180-2].

   The resulting signature is encoded as follows:

      string    "ssh-dss"
      string    dss_signature_blob

   The value for 'dss_signature_blob' is encoded as a string containing
   r, followed by s (which are 160-bit integers, without lengths or
   padding, unsigned, and in network byte order).
So, to do this, the integer versions of ?r? and ?s? are needed. Today, to use PyCA, I need to call the finalize() on a DSA signer object and then run a DER decode on the returned string to get back these integers.

For RSA, SSH defines the signature message as:
   Signing and verifying using this key format is performed according to
   the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

   The resulting signature is encoded as follows:

      string    "ssh-rsa"
      string    rsa_signature_blob

   The value for 'rsa_signature_blob' is encoded as a string containing
   s (which is an integer, without lengths or padding, unsigned, and in
   network byte order).
In this case, I didn?t have to do any decoding of the value returned by PyCA?s RSA signer object, though, suggesting that PyCA is not returning a DER-encoded value. It?s returning the result of the RSASSA-PKCS1-V1_5-SIGN function defined in RFC 3447:
   RSASSA-PKCS1-V1_5-SIGN (K, M)

   Input:
   K        signer's RSA private key
   M        message to be signed, an octet string

   Output:
   S        signature, an octet string of length k, where k is the
            length in octets of the RSA modulus n
I was able to use this in the SSH protocol directly. This suggests that the RSA & DSA implementations are inconsistent, though, with only one of them DER encoding its result.

I haven?t actually implemented a version of EC signing based on PyCA yet, so I don?t know what is returned there. However, the ECDSA signature blob for ECDSA is defined as:


   Signatures are encoded as follows:

      string   "ecdsa-sha2-[identifier]"
      string   ecdsa_signature_blob

   The string [identifier] is the identifier of the elliptic curve
   domain parameters.  The format of this string is specified in
   Section 6.1.  Information on the REQUIRED and RECOMMENDED sets of
   elliptic curve domain parameters for use with this algorithm can be
   found in Section 10.

   The ecdsa_signature_blob value has the following specific encoding:

      mpint    r
      mpint    s

   The integers r and s are the output of the ECDSA algorithm.

   The width of the integer fields is determined by the curve being
   used.  Note that the integers r and s are integers modulo the order
   of the cryptographic subgroup, which may be larger than the size of
   the finite field.

So, once again the raw ?r? and ?s? integer values would be required from the signer object to be able to construct this packet.

Because of these differences, I think there could be value in having a signing primitive in PyCA that returned the raw values rather than returning encoded versions of the values. The exact set of values to return would vary depending on the algorithm, though. For DSA & ECDSA, this would be two integers (r & s), whereas for RSA the return value is already correct (an octet string version of the integer s).


On Nov 20, 2014, at 4:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

The signers/verifiers for RSA and EC keys both use the signature in it's DER encoded format. Did you want to store/load that in a specific file format?

Alex

On Thu Nov 20 2014 at 3:51:45 PM Jesus Cea <jcea at jcea.es> wrote:
On 20/11/14 04:13, Paul Kehrer wrote:
> Thanks for your interest in the project!

Thanks for replying! :).

> We have full loading support for PEM encoded asymmetric keys (both
> traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release
> (probably in around 4 weeks) should add support for serialization back
> to disk. You can view the progress of that work
> here: https://github.com/pyca/cryptography/pull/1390

Great!. What about digital signature serialization generated from RSA
and EC keys? :-).

--
Jes?s Cea Avi?n? ? ? ? ? ? ? ? ? ? ? ? ?_/_/? ? ? _/_/_/? ? ? ? _/_/_/
jcea at jcea.es - http://www.jcea.es/? ? ?_/_/? ? _/_/? _/_/? ? _/_/? _/_/
Twitter: @jcea? ? ? ? ? ? ? ? ? ? ? ? _/_/? ? _/_/? ? ? ? ? _/_/_/_/_/
jabber / xmpp:jcea at jabber.org? _/_/? _/_/? ? _/_/? ? ? ? ? _/_/? _/_/
"Things are not so easy"? ? ? _/_/? _/_/? ? _/_/? _/_/? ? _/_/? _/_/
"My name is Dump, Core Dump"? ?_/_/_/? ? ? ? _/_/_/? ? ? _/_/? _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--?
Ron Frederick
ronf at timeheart.net



_______________________________________________  
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/20141120/911b7bd8/attachment-0001.html>

From ronf at timeheart.net  Fri Nov 21 06:58:10 2014
From: ronf at timeheart.net (Ron Frederick)
Date: Thu, 20 Nov 2014 21:58:10 -0800
Subject: [Cryptography-dev] keys and signatures import/export
In-Reply-To: <etPan.546ed100.6b8b4567.16d@atlas.local>
References: <546D0D0D.1020508@jcea.es>
 <etPan.546d5c3f.643c9869.1e5@atlas.local> <546E7E44.4080705@jcea.es>
 <CAFRnB2WDBjROAVuy_e4LiNaLmMPZ5RbMctDHP7WvQfT2nicaNw@mail.gmail.com>
 <550F8A1B-F1F1-46A2-8003-4D5CB8D6424A@timeheart.net>
 <etPan.546ed100.6b8b4567.16d@atlas.local>
Message-ID: <0D8E52F4-C477-4E07-89BC-9A400362BCA6@timeheart.net>

That?d be terrific, Paul, thanks! I?ll keep an eye out for it.

In the meantime, it was straightforward enough to work around it, but only because I happened to already have an ASN.1 decoder in AsyncSSH for other purposes.

By the way, I published version 0.9 of AsyncSSH to PyPI last week, and it now allows you to use either PyCrypto or PyCA or take algorithms from both as the basis for its crypto!

On Nov 20, 2014, at 9:43 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
> We?ve got an issue filed to track adding support for (r, s) return on DSA/ECDSA (from your original email about this actually!): https://github.com/pyca/cryptography/issues/1285
> 
> I am in favor of adding this, but haven?t spent the time to implement my most recent comment on the issue. I may try to take a look at this soon so we can get it into the seventh release.
> 
> -Paul
> On November 20, 2014 at 7:33:54 PM, Ron Frederick (ronf at timeheart.net <mailto:ronf at timeheart.net>) wrote:
> 
>> In the case of SSH, it would actually be useful to be able to get the raw ?r? and ?s? values generated when performing the DSA signing operation, as the signing operation performed in SSH (as defined in RFC 4253) for DSA keys requires sending the signature as follows:
>>    Signing and verifying using this key format is done according to the
>>    Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
>>    [FIPS-180-2].
>> 
>>    The resulting signature is encoded as follows:
>> 
>>       string    "ssh-dss"
>>       string    dss_signature_blob
>> 
>>    The value for 'dss_signature_blob' is encoded as a string containing
>>    r, followed by s (which are 160-bit integers, without lengths or
>>    padding, unsigned, and in network byte order).
>> So, to do this, the integer versions of ?r? and ?s? are needed. Today, to use PyCA, I need to call the finalize() on a DSA signer object and then run a DER decode on the returned string to get back these integers.
>> 
>> For RSA, SSH defines the signature message as:
>>    Signing and verifying using this key format is performed according to
>>    the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.
>> 
>>    The resulting signature is encoded as follows:
>> 
>>       string    "ssh-rsa"
>>       string    rsa_signature_blob
>> 
>>    The value for 'rsa_signature_blob' is encoded as a string containing
>>    s (which is an integer, without lengths or padding, unsigned, and in
>>    network byte order).
>> In this case, I didn?t have to do any decoding of the value returned by PyCA?s RSA signer object, though, suggesting that PyCA is not returning a DER-encoded value. It?s returning the result of the RSASSA-PKCS1-V1_5-SIGN function defined in RFC 3447:
>>    RSASSA-PKCS1-V1_5-SIGN (K, M)
>> 
>>    Input:
>>    K        signer's RSA private key
>>    M        message to be signed, an octet string
>> 
>>    Output:
>>    S        signature, an octet string of length k, where k is the
>>             length in octets of the RSA modulus n
>> I was able to use this in the SSH protocol directly. This suggests that the RSA & DSA implementations are inconsistent, though, with only one of them DER encoding its result.
>> 
>> I haven?t actually implemented a version of EC signing based on PyCA yet, so I don?t know what is returned there. However, the ECDSA signature blob for ECDSA is defined as:
>> 
>>    Signatures are encoded as follows:
>> 
>>       string   "ecdsa-sha2-[identifier]"
>>       string   ecdsa_signature_blob
>> 
>>    The string [identifier] is the identifier of the elliptic curve
>>    domain parameters.  The format of this string is specified in
>>    Section 6.1 <http://tools.ietf.org/html/rfc5656#section-6.1>.  Information on the REQUIRED and RECOMMENDED sets of
>>    elliptic curve domain parameters for use with this algorithm can be
>>    found in Section 10 <http://tools.ietf.org/html/rfc5656#section-10>.
>> 
>>    The ecdsa_signature_blob value has the following specific encoding:
>> 
>>       mpint    r
>>       mpint    s
>> 
>>    The integers r and s are the output of the ECDSA algorithm.
>> 
>>    The width of the integer fields is determined by the curve being
>>    used.  Note that the integers r and s are integers modulo the order
>>    of the cryptographic subgroup, which may be larger than the size of
>>    the finite field.
>> 
>> So, once again the raw ?r? and ?s? integer values would be required from the signer object to be able to construct this packet.
>> 
>> Because of these differences, I think there could be value in having a signing primitive in PyCA that returned the raw values rather than returning encoded versions of the values. The exact set of values to return would vary depending on the algorithm, though. For DSA & ECDSA, this would be two integers (r & s), whereas for RSA the return value is already correct (an octet string version of the integer s).
>> 
>> 
>>> On Nov 20, 2014, at 4:21 PM, Alex Gaynor <alex.gaynor at gmail.com <mailto:alex.gaynor at gmail.com>> wrote:
>>> 
>>> The signers/verifiers for RSA and EC keys both use the signature in it's DER encoded format. Did you want to store/load that in a specific file format?
>>> 
>>> Alex
>>> 
>>> On Thu Nov 20 2014 at 3:51:45 PM Jesus Cea <jcea at jcea.es <mailto:jcea at jcea.es>> wrote:
>>> On 20/11/14 04:13, Paul Kehrer wrote:
>>> > Thanks for your interest in the project!
>>> 
>>> Thanks for replying! :).
>>> 
>>> > We have full loading support for PEM encoded asymmetric keys (both
>>> > traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release
>>> > (probably in around 4 weeks) should add support for serialization back
>>> > to disk. You can view the progress of that work
>>> > here: https://github.com/pyca/cryptography/pull/1390 <https://github.com/pyca/cryptography/pull/1390>
>>> 
>>> Great!. What about digital signature serialization generated from RSA
>>> and EC keys? :-).
>>> 
>>> --
>>> Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
>>> jcea at jcea.es <mailto:jcea at jcea.es> - http://www.jcea.es/ <http://www.jcea.es/>     _/_/    _/_/  _/_/    _/_/  _/_/
>>> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
>>> jabber / xmpp:jcea at jabber.org <mailto:xmpp%3Ajcea at jabber.org>  _/_/  _/_/    _/_/          _/_/  _/_/
>>> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
>>> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
>>> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-- 
Ron Frederick
ronf at timeheart.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/862f6141/attachment.html>