[OLPC Security] [Techteam] Crypto export and python-crypto

[Jameson "Chema" Quinn]

On Mon, Jun 2, 2008 at 3:26 PM, C. Scott Ananian <cscott at laptop.org> wrote:

> In email, Morgan writes:
> > Jameson Chema Quinn is basing his crypto code for bundle signing on
> python-crypto: http://www.amk.ca/python/code/crypto.html
>
> I personally would prefer that crypto code be based on the same
> algorithms and formats we use elsewhere, as documented at:
>
> http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease
>

On algorithms, I fully agree. Signatures, for instance, should be based on
pkcs1v2.1.

On formats, I agree in principle. But as your own email points out, there
are already two different signature formats invented for the XO, because of
specifics about what is to be signed. If these do not work for my needs, I
do not see why I should not invent another.


>
> I took great care to ensure that the every bit in the format is
> documented, and traceable in most cases to best practices outlined in
> a standards document.  This is in marked contrast to places where
> you'll find handwaving about "an RSA signature" (say) when there are
> multiple ways to use RSA to generate a signature, many of them in fact
> terribly bad.  (For example, OpenPGP uses an RSA signature scheme
> vulnerable to an adaptive chosen ciphertext attack, and the known
> covert channels in DSA signatures became very problematic in the
> recent Debian/OpenSSL issues.)


The OpenPGP attack you mention has to do with encryption, not signatures.
(And it leaks a tiny fraction of plaintext for 2^16 encryption operations
per block). Signatures, becauses they cannot fail partially like this, are
inherently more secure than encryption; a mistake like this in a signature
would just reduce the exponent on the difficulty of forgery by a small
amount, making no practical difference.


>
>
> Python bindings are at
> http://dev.laptop.org/git?p=bios-crypto;a=summary and are available in
> the olpccontents RPM on the XO.


Now you're talking. I will still have to embed these signatures in a format
to fit my purposes, but it appears I can use this code instead of pycrypto.

>
>
> Avoiding the need to declare additional crypto code for export is a
> pleasant side effect of using the existing audited codebase; Michael
> can tell you the extent to which that is (or is not) necessary in the
> case of python-crypto.  I don't see anything in python-crypto which is
> not included in bios-crypto; most of what python-crypto provides is
> either out-of-date (should not be used in new applications) or
> duplicates functionality already provided by the standard python
> libraries (http://docs.python.org/lib/crypto.html).


The standard libraries provide only hash functionality. Pycrypto provides
symmetric and public-key ciphers. I think it would be good in the long term
to have good python bindings for these latter functions - but since with
what you've given me I don't need that, I will let that lie. (Openpgp may be
the right solution here).

>
>
> Security-sensitive code should also be reviewed on the security list.
> >From a software engineering standpoint, I'd be much happier if we just
> decided to use JAR files
> http://en.wikipedia.org/wiki/JAR_(file_format)<http://en.wikipedia.org/wiki/JAR_%28file_format%29>which already have a
> well-defined signature mechanism, instead of designing our own bespoke
> thing yet again (see
> http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2 and
> http://wiki.laptop.org/go/Contents_manifest_specification ).
>  --scott
>

I did look at JAR files, and decided that their format lacked some desirable
features. They are based on md5 hashes, which are close to broken; they do
not allow for granting privileges to secondary keys, which means that
Glucose can't take any of the key management burden off the shoulders of the
user; they interact poorly with differential versioning storage; and they do
not allow for unsigned content in a signed bundle, which makes localization
more of a pain. Any one of those problems I could have lived with, the three
together seem to me like a good enough reason for changing a format. And
once you make any change, you break existing tools, so there is no reason to
the format partially.

The contents manifest specification does not fit my needs either.

Thanks for responding, I hope to continue the dialog,
Jameson Quinn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/620e86e6/attachment.htm