Zitat von Daniel Holth <dho...@gmail.com>:
Well, let's try again. I know Ed25519 is not on anyone's list, but I
would like to show at minimum that it is interesting.
I have no doubt about that, and I believe that this ("it is interesting")
might be your primary motivation for using it, i.e. "coolness", which
is really a form of purity.
%timeit wheel.tool.unpack('lxml-3.0.1-cp27-none-linux_x86_64.whl')
1 loops, best of 3: 153 ms per loop
With python-ecdsa, verifying a single signature,
import ecdsa
sk = ecdsa.SigningKey.generate(ecdsa.NIST256p)
sig = sk.sign("message")
vk = sk.get_verifying_key()
%timeit vk.verify(sig, "message")
1 loops, best of 3: 144 ms per loop
takes about as long as the whole unpack() including verification.
This isn't really convincing, as you are comparing different operations.
It may well be that in pure-python ed25519, it's also the validation
that takes most of the time.
But it's really irrelevant. We are talking about a runtime of 0.1s.
If this really becomes an issue, an openssl version can be used instead.
Also python-ecdsa does not work on Python 3.
Which certainly can be fixed.
If necessary we could also just remove algorithms from the spec and
make the signing implementation pluggable. For key management reasons,
the signing interface used by the build tool is already "run the wheel
command line tool in a subprocess" which is also what you would do if
you needed to take advantage of the allowed S/MIME RECORD.p7s.
I'm also -1 on the notion that the entire key distribution matter is out
of scope. With that approach, I feel that the package signing is essentially
pointless.
As a general note on this, this entire issue lacks a threat model:
what kind of attack do you want to protect against? I can't think of
any realistic threat that is effectively protected against with your
signature scheme.
Regards,
Martin
_______________________________________________
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
