On Thu, Oct 18, 2012 at 3:37 PM, Daniel Holth <dho...@gmail.com> wrote:
> On Thu, Oct 18, 2012 at 2:21 PM, <mar...@v.loewis.de> wrote:
>> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use
>> JSON
>> Web signatures, this algorithm is not supported by the current JWS draft
>> [1].
>>
>> Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the
>> NIST P-256 curve and SHA-256. This has the advantage of using standard
>> algorithms [2].
>>
>> I don't know what the rationale for suggesting ed25519 is; I suppose that
>> existence of a pure-Python implementation played a role. However:
>> - ECDSA also has a pure-Python implementation
>> - ECDSA is well-supported by OpenSSL, i.e. a signature generator may also
>> invoke the OpenSSL command line for efficient implementation. I believe
>> M2Crypto also exposes enough of OpenSSL tp perform ECDSA signing and
>> verification.
Added a FAQ entry:
Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA?
Wheel's signing scheme is designed to protect against cryptography
that is not used. Wheel tries to encourage signing by making it very
fast and easy. Signature verification is encouraged by including
the signature in the archive itself rather than making it a separate
download, and by including a Python implementation of the entire
signing system in the reference implementation.
JWS and Ed25519 yield small, pure-Python implementations. Ed25519
is fast enough that public-key cryptography can be considered for
applications where it was traditionally too slow to be used, so
wheels can be signed without worrying about performance. In Ed25519,
unlike ECDSA, only key generation, but not signing, depends on
a continuing high-quality source of entropy. The combination of
increased performance, convenience, and availability compared to
using a separate program means digital signatures can always be
enabled in wheel.
Wheel uses simplified keys and a signature system where key generation
is about as fast as signing, making it possible to consider signing
keys an abundant resource. Keys could represent a build server or
a package rather than the publisher's entire digital identity.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
