From terrycwk1994 at gmail.com  Tue Jul  1 08:56:45 2014
From: terrycwk1994 at gmail.com (Terry Chia)
Date: Tue, 1 Jul 2014 14:56:45 +0800
Subject: [Cryptography-dev] GCM tag truncation, backwards compatibility
In-Reply-To: <146ee99eea0.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at>
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>
 <146ee99eea0.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at>
Message-ID: <CAGqxZSWF6ZWm6RTFpb_xMiLt0z91KKZ-Y0RpSDATF89ree11vg@mail.gmail.com>

I don't think we should remove the ability to truncate tags given that
it is explicitly allowed by the standards and that this is in the
hazmat layer after all. Requiring opt-in for truncation should be good
enough.

On Tue, Jul 1, 2014 at 5:06 AM, Alex Stapleton <alexs at prol.etari.at> wrote:
> 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
>>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>

From paul.l.kehrer at gmail.com  Mon Jul  7 20:25:22 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Mon, 7 Jul 2014 13:25:22 -0500
Subject: [Cryptography-dev] PyCA cryptography 0.5 released!
Message-ID: <etPan.53bae612.140e0f76.35a@atlas.local>

On behalf of all the contributors to PyCA cryptography I?m pleased to announce that version 0.5 has been released and is now available on PyPI. This release encompasses 497 commits from 140 separate pull requests.

A few major changes of note:

* OpenSSL is now bundled in our Windows wheels to improve the install experience on that platform.
* Elliptic curve support was added.
* The asymmetric key handling was reworked to allow backend specific key representation. This was done to support a wider variety of backends with varying capabilities in the future.

You can see the full changelog here:?https://cryptography.io/en/latest/changelog/

Master will be reopening shortly for development on the sixth release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140707/cd890957/attachment.html>

From paul.l.kehrer at gmail.com  Tue Jul  8 05:27:45 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Mon, 7 Jul 2014 22:27:45 -0500
Subject: [Cryptography-dev] PyCA cryptography 0.5.1 released
Message-ID: <etPan.53bb6531.7c83e458.35a@atlas>

I?ve just released 0.5.1 to PyPI. This is a small release to address an issue where PKCS8SerializationBackend was not implemented on MultiBackend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140707/2c86957a/attachment.html>

From paul.l.kehrer at gmail.com  Thu Jul 10 03:33:27 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Wed, 9 Jul 2014 20:33:27 -0500
Subject: [Cryptography-dev] PyCA cryptography 0.5.2 released
Message-ID: <etPan.53bded67.628c895d.35a@atlas>

0.5.2 has just been released to PyPI. This is another small bugfix release to handle a compilation error on OS X Mountain Lion (10.8) and add the TraditionalOpenSSLSerializationBackend to MultiBackend.

To prevent recurrence of the OS X error the jenkins Mavericks builders are being switched to Mountain Lion. Mavericks will continue to be tested via Travis CI (which switched to Mavericks from ML builders several months ago).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140709/f65f2c26/attachment.html>

From donald at stufft.io  Thu Jul 24 05:11:40 2014
From: donald at stufft.io (Donald Stufft)
Date: Wed, 23 Jul 2014 23:11:40 -0400
Subject: [Cryptography-dev] Domain Name Renewed
Message-ID: <etPan.53d0796c.507ed7ab.11ea@Thor.local>

Just a FYI that I just renewed the cryptography.io domain name for another year.

--?
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/20140723/e9a0d43d/attachment.html>

From ronf at timeheart.net  Sat Jul 26 21:52:32 2014
From: ronf at timeheart.net (Ron Frederick)
Date: Sat, 26 Jul 2014 12:52:32 -0700
Subject: [Cryptography-dev] Asymmetric signing primitives
Message-ID: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>

Hello,

I recently began looking at adding support for PyCA to my AsyncSSH package (http://asyncssh.timeheart.net). It currently uses PyCrypto, but I see a lot of potential in being able to directly use OpenSSL and other more carefully scrutinized crypto libraries from a security perspective.

In the process of adding this support, I ran into an issue with DSA signing and verification. The current implementation in PyCA seems to ASN.1 encode the signature it produces before returning it, while the SSH protocol requires a different encoding to be used of the raw ?r? and ?s? values. I?ve worked around this for now by doing my own ASN.1 code of the return result before re-encoding it in the form SSH needs, but this is somewhat wasteful. I was wondering if it might be possible to provide an option or alternate API which would return the raw r & s values as integers, for protocols that want to use an encoding other than ASN.1.

As I worked with these asymmetric key classes, I also noticed a bit of an inconsistency in the API used to access the various raw numbers that go into making up the keys. The current API uses a mixture of method calls and properties, and provides different ways to access some of the values depending on whether you are working with public or private keys. I think it would be good to make this a bit more consistent, at least about method calls vs. properties, but also ideally to provide a common way to access all the values common to public & private keys using the same API, with additional API calls for private keys to access values only applicable there.

As an example of what I?m talking about, here are the calls needed to access the parameters of a DSA public key today:

p: key.parameters().parameter_numbers().p
q: key.parameters().parameter_numbers().q
g: key.parameters().parameter_numbers().g
y: key.public_numbers().y

Note how in one case you can get to the public numbers directly, whereas in the other you have to go through an intermediate object first. It would be nice there to have parameter_numbers() available directly from the key similar to public_numbers(), at least as a convenience function. I would keep the existing parameters() function as well, as it has value to extract the parameters as a group to use in creating other keys. However, allowing access either that way or directly to the numbers object would be nice.

For a DSA private key, the first three calls are the same, but the call to get the ?y? value is different:

y: key.private_numbers().public_numbers.y

Also, note here how public_numbers is a property of the object returned by private_numbers(), rather than being a function call the way it is above. Again, it would be nice if private keys had parameter_numbers(), public_numbers(), and private_numbers() calls to expose these values directly, in a way consistent with public keys.

The final call to get the private numbers is already consistent with this:

x: key.private_numbers().x

What I?m suggesting is something that looks more like:

p: key.parameter_numbers().p
q: key.parameter_numbers().q
g: key.parameter_numbers().g
y: key.public_numbers().y
x: key.private_numbers().x

RSA keys have similar issues. The current calls for public keys are:

n: key.public_numbers().n
e: key.public_numbers().e

However, the calls for private keys are:

n: key.private_numbers().public_numbers.n
e: key.private_numbers().public_numbers.e
d: key.private_numbers().d
p: key.private_numbers().p
q: key.private_numbers().q

Having a directly callable public_numbers() function on both the public & private key classes here would be convenient.

Finally, if I may, I have one final suggestion. It would be convenient to have the update() function return self (the signer object). That way, it would be possible to write something like:

        signature = key.signer(PKCS1v15(), SHA1()).update(data).finalize()

instead of:

        signer = self._key.signer(PKCS1v15(), SHA1())
        signer.update(data)
        signature = signer.finalize()

in cases where you had only a single block of data to pass in.

Thank you for listening, and for all the work that has gone into this package so far!
-- 
Ron Frederick
ronf at timeheart.net

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

From paul.l.kehrer at gmail.com  Sun Jul 27 02:11:01 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Sat, 26 Jul 2014 19:11:01 -0500
Subject: [Cryptography-dev] Asymmetric signing primitives
In-Reply-To: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
References: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
Message-ID: <etPan.53d44395.6ceaf087.35a@atlas>

Ron, thank you very much for the feedback. I?ve added my comments inline.

On July 26, 2014 at 2:52:41 PM, Ron Frederick (ronf at timeheart.net) wrote:

Hello,

I recently began looking at adding support for PyCA to my AsyncSSH package (http://asyncssh.timeheart.net). It currently uses PyCrypto, but I see a lot of potential in being able to directly use OpenSSL and other more carefully scrutinized crypto libraries from a security perspective.

In the process of adding this support, I ran into an issue with DSA signing and verification. The current implementation in PyCA seems to ASN.1 encode the signature it produces before returning it, while the SSH protocol requires a different encoding to be used of the raw ?r? and ?s? values. I?ve worked around this for now by doing my own ASN.1 code of the return result before re-encoding it in the form SSH needs, but this is somewhat wasteful. I was wondering if it might be possible to provide an option or alternate API which would return the raw r & s values as integers, for protocols that want to use an encoding other than ASN.1.


We?ve talked about adding alternate APIs to get the raw (r, s) tuple out of the DSA signature but we?ve been conflicted about whether we wanted to add a dependency on pyasn1 or if we just want to write some code that handles ASN.1 sequences and integers ourselves. How did you approach it? Filed as:?https://github.com/pyca/cryptography/issues/1285

As I worked with these asymmetric key classes, I also noticed a bit of an inconsistency in the API used to access the various raw numbers that go into making up the keys. The current API uses a mixture of method calls and properties, and provides different ways to access some of the values depending on whether you are working with public or private keys. I think it would be good to make this a bit more consistent, at least about method calls vs. properties, but also ideally to provide a common way to access all the values common to public & private keys using the same API, with additional API calls for private keys to access values only applicable there.

As an example of what I?m talking about, here are the calls needed to access the parameters of a DSA public key today:

p: key.parameters().parameter_numbers().p
q:?key.parameters().parameter_numbers().q
g:?key.parameters().parameter_numbers().g
y:?key.public_numbers().y

Note how in one case you can get to the public numbers directly, whereas in the other you have to go through an intermediate object first. It would be nice there to have parameter_numbers() available directly from the key similar to public_numbers(), at least as a convenience function. I would keep the existing parameters() function as well, as it has value to extract the parameters as a group to use in creating other keys. However, allowing access either that way or directly to the numbers object would be nice.
This seems reasonable to me. If we do this we would add it to the DSAPublicKeyWithNumbers and DSAPrivateKeyWithNumbers interfaces. Filed as?https://github.com/pyca/cryptography/issues/1286



For a DSA private key, the first three calls are the same, but the call to get the ?y? value is different:

y:?key.private_numbers().public_numbers.y


Hmm, yes, the inconsistency between function and attribute here is definitely confusing. Filed as?https://github.com/pyca/cryptography/issues/1288





Also, note here how public_numbers is a property of the object returned by private_numbers(), rather than being a function call the way it is above. Again, it would be nice if private keys had parameter_numbers(), public_numbers(), and private_numbers() calls to expose these values directly, in a way consistent with public keys.

The final call to get the private numbers is already consistent with this:

x: key.private_numbers().x

What I?m suggesting is something that looks more like:

p: key.parameter_numbers().p
q:?key.parameter_numbers().q
g:?key.parameter_numbers().g
y:?key.public_numbers().y
x: key.private_numbers().x

RSA keys have similar issues. The current calls for public keys are:

n: key.public_numbers().n
e:?key.public_numbers().e

However, the calls for private keys are:

n: key.private_numbers().public_numbers.n
e:?key.private_numbers().public_numbers.e
d:?key.private_numbers().d
p:?key.private_numbers().p
q:?key.private_numbers().q

Having a directly callable public_numbers() function on both the public & private key classes here would be convenient.


Agreed. Like DSA this would be accomplished by expanding the WithNumbers interfaces and implementing the methods on the backend specific implementations. (https://github.com/pyca/cryptography/issues/1286)





Finally, if I may, I have one final suggestion. It would be convenient to have the update() function return self (the signer object). That way, it would be possible to write something like:

? ? ? ? signature = key.signer(PKCS1v15(), SHA1()).update(data).finalize()

instead of:

? ? ? ??signer = self._key.signer(PKCS1v15(), SHA1())
? ? ? ? signer.update(data)
? ? ? ? signature =?signer.finalize()

in cases where you had only a single block of data to pass in.


This also sounds like a good idea (that we should consider doing for all our update/finalize APIs). Filed as?https://github.com/pyca/cryptography/issues/1287





Thank you for listening, and for all the work that has gone into this package so far!




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

From ronf at timeheart.net  Sun Jul 27 02:39:24 2014
From: ronf at timeheart.net (Ron Frederick)
Date: Sat, 26 Jul 2014 17:39:24 -0700
Subject: [Cryptography-dev] Asymmetric signing primitives
In-Reply-To: <etPan.53d44395.6ceaf087.35a@atlas>
References: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
 <etPan.53d44395.6ceaf087.35a@atlas>
Message-ID: <CF16F78D-D394-498B-B712-F49BC41AE8A7@timeheart.net>

Hi Paul,

Thanks for the quick response, and for filing these! Some follow-up comments inline below.

On Jul 26, 2014, at 5:11 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
> On July 26, 2014 at 2:52:41 PM, Ron Frederick (ronf at timeheart.net) wrote:
>> In the process of adding this support, I ran into an issue with DSA signing and verification. The current implementation in PyCA seems to ASN.1 encode the signature it produces before returning it, while the SSH protocol requires a different encoding to be used of the raw ?r? and ?s? values. I?ve worked around this for now by doing my own ASN.1 code of the return result before re-encoding it in the form SSH needs, but this is somewhat wasteful. I was wondering if it might be possible to provide an option or alternate API which would return the raw r & s values as integers, for protocols that want to use an encoding other than ASN.1.
> 
> We?ve talked about adding alternate APIs to get the raw (r, s) tuple out of the DSA signature but we?ve been conflicted about whether we wanted to add a dependency on pyasn1 or if we just want to write some code that handles ASN.1 sequences and integers ourselves. How did you approach it? Filed as: https://github.com/pyca/cryptography/issues/1285

In terms of ASN.1, I needed an implementation of basic DER encoding/decoding for reading and writing public & private keys for SSH, so I wrote my own module for it. While it doesn?t handle all of what ASN.1 allows (and in particular focuses on DER rather than the more general BER encoding), it works well for DER as used in keys, and was good enough to handle this case. It?s self-contained and only a little over 500 lines of code (including comments).

If this is something you?d be interested including in PyCA, I?d be happy to contribute it. It?s currently available under the Eclipse Public License, but I?d happy to relicense it under the Apache license to make it compatible. If you?d like to look at the code, you can find it at:

    https://github.com/ronf/asyncssh/blob/master/asyncssh/asn1.py

That said, would you need to do the ASN.1 encoding and decoding? I was hoping there?d be a way to call into a lower-level routine which computed r & s but didn?t encode them. I haven?t specifically looked to see if OpenSSL has such a call, though. If not, it might require using the bignum math functions there to reimplement the signing.


>> As I worked with these asymmetric key classes, I also noticed a bit of an inconsistency in the API used to access the various raw numbers that go into making up the keys. The current API uses a mixture of method calls and properties, and provides different ways to access some of the values depending on whether you are working with public or private keys. I think it would be good to make this a bit more consistent, at least about method calls vs. properties, but also ideally to provide a common way to access all the values common to public & private keys using the same API, with additional API calls for private keys to access values only applicable there.
>> 
>> As an example of what I?m talking about, here are the calls needed to access the parameters of a DSA public key today:
>> 
>> p: key.parameters().parameter_numbers().p
>> q: key.parameters().parameter_numbers().q
>> g: key.parameters().parameter_numbers().g
>> y: key.public_numbers().y
>> 
>> Note how in one case you can get to the public numbers directly, whereas in the other you have to go through an intermediate object first. It would be nice there to have parameter_numbers() available directly from the key similar to public_numbers(), at least as a convenience function. I would keep the existing parameters() function as well, as it has value to extract the parameters as a group to use in creating other keys. However, allowing access either that way or directly to the numbers object would be nice.
> 
> This seems reasonable to me. If we do this we would add it to the DSAPublicKeyWithNumbers and DSAPrivateKeyWithNumbers interfaces. Filed as https://github.com/pyca/cryptography/issues/1286
> 
Sounds good.


>> For a DSA private key, the first three calls are the same, but the call to get the ?y? value is different:
>> 
>> y: key.private_numbers().public_numbers.y
> 
> Hmm, yes, the inconsistency between function and attribute here is definitely confusing. Filed as https://github.com/pyca/cryptography/issues/1288
> 
>> Also, note here how public_numbers is a property of the object returned by private_numbers(), rather than being a function call the way it is above. Again, it would be nice if private keys had parameter_numbers(), public_numbers(), and private_numbers() calls to expose these values directly, in a way consistent with public keys.
>> 
>> The final call to get the private numbers is already consistent with this:
>> 
>> x: key.private_numbers().x
>> 
>> What I?m suggesting is something that looks more like:
>> p: key.parameter_numbers().p
>> q: key.parameter_numbers().q
>> g: key.parameter_numbers().g
>> y: key.public_numbers().y
>> x: key.private_numbers().x
>> 
>> RSA keys have similar issues. The current calls for public keys are:
>> 
>> n: key.public_numbers().n
>> e: key.public_numbers().e
>> 
>> However, the calls for private keys are:
>> 
>> n: key.private_numbers().public_numbers.n
>> e: key.private_numbers().public_numbers.e
>> d: key.private_numbers().d
>> p: key.private_numbers().p
>> q: key.private_numbers().q
>> 
>> Having a directly callable public_numbers() function on both the public & private key classes here would be convenient.
> 
> Agreed. Like DSA this would be accomplished by expanding the WithNumbers interfaces and implementing the methods on the backend specific implementations. (https://github.com/pyca/cryptography/issues/1286)
> 
Yup, makes sense.


>> Finally, if I may, I have one final suggestion. It would be convenient to have the update() function return self (the signer object). That way, it would be possible to write something like:
>> 
>>         signature = key.signer(PKCS1v15(), SHA1()).update(data).finalize()
>> 
>> instead of:
>> 
>>         signer = self._key.signer(PKCS1v15(), SHA1())
>>         signer.update(data)
>>         signature = signer.finalize()
>> 
>> in cases where you had only a single block of data to pass in.
> 
> 
> This also sounds like a good idea (that we should consider doing for all our update/finalize APIs). Filed as https://github.com/pyca/cryptography/issues/1287
> 
On the update()/finalize() issue, I noticed after sending my last mail that in the case of symmetric encryption/decryption, update() returns some amount of the encrypted/decrypted data each time it is called, so returning ?self? wouldn?t be as easy there. Another option might be to allow finalize() to take optional data as an argument, though, or perhaps instead to provide sign() and verify() functions on the key classes which do the equivalent of calling signer/verifier, update, and finalize all in a single call (in addition to the current calls to use when you want to send in multiple blocks of data).
-- 
Ron Frederick
ronf at timeheart.net



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

From glyph at twistedmatrix.com  Sun Jul 27 20:58:41 2014
From: glyph at twistedmatrix.com (Glyph)
Date: Sun, 27 Jul 2014 11:58:41 -0700
Subject: [Cryptography-dev] Asymmetric signing primitives
In-Reply-To: <etPan.53d44395.6ceaf087.35a@atlas>
References: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
 <etPan.53d44395.6ceaf087.35a@atlas>
Message-ID: <6C1674C0-13A6-4B95-9DFD-ACF351BC386B@twistedmatrix.com>


On Jul 26, 2014, at 5:11 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> We?ve talked about adding alternate APIs to get the raw (r, s) tuple out of the DSA signature but we?ve been conflicted about whether we wanted to add a dependency on pyasn1 or if we just want to write some code that handles ASN.1 sequences and integers ourselves. How did you approach it? Filed as: https://github.com/pyca/cryptography/issues/1285

Just to add my 2? to this debate:

Let's (or, to the extent that I am lazy and have not put any PRs forward yet, "you should") add a dependency on pyasn1, and contribute upstream to pyasn1 if there are issues that make it problematic to depend upon.  Much like we shouldn't have lots of ad-hoc repeated crypto code because of the gravity of potential errors, there shouldn't be lots of ad-hoc repeated asn.1 processing code, because it's just as security-critical.

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

From donald at stufft.io  Sun Jul 27 21:01:26 2014
From: donald at stufft.io (Donald Stufft)
Date: Sun, 27 Jul 2014 15:01:26 -0400
Subject: [Cryptography-dev] Asymmetric signing primitives
In-Reply-To: <6C1674C0-13A6-4B95-9DFD-ACF351BC386B@twistedmatrix.com>
References: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
 <etPan.53d44395.6ceaf087.35a@atlas>
 <6C1674C0-13A6-4B95-9DFD-ACF351BC386B@twistedmatrix.com>
Message-ID: <etPan.53d54c86.721da317.4c3e@Thor.local>


On July 27, 2014 at 2:58:59 PM, Glyph (glyph at twistedmatrix.com) wrote:
>  
> On Jul 26, 2014, at 5:11 PM, Paul Kehrer wrote:
>  
> > We?ve talked about adding alternate APIs to get the raw (r, s) tuple out of the DSA signature  
> but we?ve been conflicted about whether we wanted to add a dependency on pyasn1 or if we  
> just want to write some code that handles ASN.1 sequences and integers ourselves. How  
> did you approach it? Filed as: https://github.com/pyca/cryptography/issues/1285  
>  
> Just to add my 2? to this debate:
>  
> Let's (or, to the extent that I am lazy and have not put any PRs forward yet, "you should")  
> add a dependency on pyasn1, and contribute upstream to pyasn1 if there are issues that  
> make it problematic to depend upon. Much like we shouldn't have lots of ad-hoc repeated  
> crypto code because of the gravity of potential errors, there shouldn't be lots of ad-hoc  
> repeated asn.1 processing code, because it's just as security-critical.
>  

Also because dependencies are not bad things and reimplementing logic is bad unless we have some sort of reasoning where pyasn1 is so broken that it?d be easier to start over than reuse it or the maintainer refuses to fix issues.

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

From sam at samkronick.com  Mon Jul 28 17:00:13 2014
From: sam at samkronick.com (sam at samkronick.com)
Date: Mon, 28 Jul 2014 17:00:13 +0200
Subject: [Cryptography-dev] Cross compile for OpenWRT/MIPS?
Message-ID: <A9D7DBD1-8381-4193-A43B-267D726C13C0@samkronick.com>

Hi all,
I?m trying to get a python library (mitmproxy/libmproxy) running on OpenWRT (https://openwrt.org/) on a router with a MIPS CPU. mitmproxy depends on cryptography, and I?m getting stuck trying to cross-compile cryptography for MIPS using the OpenWRT SDK.

I have the cross compiler set up and have cross compiled a few python libraries with c code so I know that works (following http://whatschrisdoing.com/blog/2009/10/16/cross-compiling-python-extensions/). The issue I?m having seems to be with cffi? it?s cross-compiling the c code from cryptography, but then it tries to load that and execute it on the build machine which throws a cffi.ffiplatform.VerificationError complaining ?wrong ELF class: ELFCLASS32? Of course it can?t run the code that was compiled for another architecture, but is there any way around this? There is no native compiler available for OpenWRT, so cross-compiling seems necessary.

Any ideas?

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

From paul.l.kehrer at gmail.com  Tue Jul 29 18:25:50 2014
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Tue, 29 Jul 2014 11:25:50 -0500
Subject: [Cryptography-dev] Asymmetric signing primitives
In-Reply-To: <etPan.53d54c86.721da317.4c3e@Thor.local>
References: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
 <etPan.53d44395.6ceaf087.35a@atlas>
 <6C1674C0-13A6-4B95-9DFD-ACF351BC386B@twistedmatrix.com>
 <etPan.53d54c86.721da317.4c3e@Thor.local>
Message-ID: <etPan.53d7cb0e.6b8b4567.1209@atlas.local>

I?m convinced. I?m actually working on the CC backend RSA support at the moment and will modify the existing work to use pyasn1. We can discuss it more once it?s up for review.

On July 27, 2014 at 2:01:40 PM, Donald Stufft (donald at stufft.io) wrote:


On July 27, 2014 at 2:58:59 PM, Glyph (glyph at twistedmatrix.com) wrote:
>  
> On Jul 26, 2014, at 5:11 PM, Paul Kehrer wrote:
>  
> > We?ve talked about adding alternate APIs to get the raw (r, s) tuple out of the DSA signature  
> but we?ve been conflicted about whether we wanted to add a dependency on pyasn1 or if we  
> just want to write some code that handles ASN.1 sequences and integers ourselves. How  
> did you approach it? Filed as: https://github.com/pyca/cryptography/issues/1285  
>  
> Just to add my 2? to this debate:
>  
> Let's (or, to the extent that I am lazy and have not put any PRs forward yet, "you should")  
> add a dependency on pyasn1, and contribute upstream to pyasn1 if there are issues that  
> make it problematic to depend upon. Much like we shouldn't have lots of ad-hoc repeated  
> crypto code because of the gravity of potential errors, there shouldn't be lots of ad-hoc  
> repeated asn.1 processing code, because it's just as security-critical.
>  

Also because dependencies are not bad things and reimplementing logic is bad unless we have some sort of reasoning where pyasn1 is so broken that it?d be easier to start over than reuse it or the maintainer refuses to fix issues.

--  
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/20140729/2bf80e25/attachment.html>

From glyph at twistedmatrix.com  Wed Jul 30 02:13:56 2014
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Tue, 29 Jul 2014 17:13:56 -0700
Subject: [Cryptography-dev] Asymmetric signing primitives
In-Reply-To: <etPan.53d54c86.721da317.4c3e@Thor.local>
References: <7D19CA2D-E007-4B6C-AA02-CCF7EF7996EC@timeheart.net>
 <etPan.53d44395.6ceaf087.35a@atlas>
 <6C1674C0-13A6-4B95-9DFD-ACF351BC386B@twistedmatrix.com>
 <etPan.53d54c86.721da317.4c3e@Thor.local>
Message-ID: <72BCA2B3-DE3E-4AD0-ACF4-726C9192D9C3@twistedmatrix.com>


On Jul 27, 2014, at 12:01 PM, Donald Stufft <donald at stufft.io> wrote:

> Also because dependencies are not bad things and reimplementing logic is bad unless we have some sort of reasoning where pyasn1 is so broken that it?d be easier to start over than reuse it or the maintainer refuses to fix issues.

It seems like at some point we may need to interoperate with higher-level APIs that do things with parsed ASN.1 data structures within each backend.  But we're not there now :-).

-glyph

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