Custom Query (72 matches)
Results (46 - 48 of 72)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #36 | fixed | Allow pycryptopp installation from setuptools | zooko | Nikratio |
| Description |
Hello, I have specified pycryptopp as an external dependency in my Python module. When pycryptopp is not yet installed, setuptools automatically downloads and (tries) to install it. However, for some reason this does not work. Here is the output that I get: $ ./setup.py test running test Searching for pycryptopp Reading http://pypi.python.org/simple/pycryptopp/ Reading http://allmydata.org/trac/pycryptopp Reading http://allmydata.org/source/pycryptopp Reading http://allmydata.org/source/zfec Best match: pycryptopp 0.5.17 Downloading http://pypi.python.org/packages/source/p/pycryptopp/pycryptopp-0.5.17.tar.gz#md5=b3d19e7203531f8bd241ae58062f99e4 Processing pycryptopp-0.5.17.tar.gz Running pycryptopp-0.5.17/setup.py -q bdist_egg --dist-dir /tmp/easy_install-ZMeM89/pycryptopp-0.5.17/egg-dist-tmp-BlCkIO Traceback (most recent call last):
TypeError?: use_setuptools() got an unexpected keyword argument 'min_version' It would be really nice if this could be made to work. |
|||
| #34 | fixed | Segmentation Fault in function X86_SHA256_HashBlocks | warner | francois |
| Description |
Sometimes I get a segfault when I launch Tahoe's 'make test' on my Ubuntu karmic 64 bit workstation. Thanks to 'ulimit -c unlimited' a coredump was generated. Here's what gdb has to tell. Core was generated by `python setup.py test -s allmydata'. Program terminated with signal 11, Segmentation fault. #0 0x00002b1fdf884efc in X86_SHA256_HashBlocks (this=<value optimized out>, input=0x30456e4, length=47412143980619) at cryptopp/sha.cpp:435 435 cryptopp/sha.cpp: No such file or directory. in cryptopp/sha.cpp Here is the interesting part of the stacktrace: #0 0x00002b1fdf884efc in X86_SHA256_HashBlocks (this=<value optimized out>, input=0x30456e4, length=47412143980619) at cryptopp/sha.cpp:435
#1 CryptoPP::SHA256::HashMultipleBlocks (this=<value optimized out>, input=0x30456e4, length=47412143980619) at cryptopp/sha.cpp:453
#2 0x00002b1fdf88311e in CryptoPP::IteratedHashBase<unsigned int, CryptoPP::HashTransformation>::Update(unsigned char const*, unsigned long) ()
from /usr/local/lib/python2.6/dist-packages/pycryptopp-0.5.15-py2.6-linux-x86_64.egg/pycryptopp/_pycryptopp.so
#3 0x00002b1fdf826004 in CryptoPP::PK_MessageAccumulatorBase::Update (this=0x3cc6940, input=0x30456e4 "", length=47412143980619) at cryptopp/pubkey.h:292
#4 0x00002b1fdf872419 in CryptoPP::PK_Verifier::VerifyMessage (this=0x67eb720, message=0x30456e4 "", messageLen=47412143980619, signature=0x38e1c24 "\001s\001\205",
signatureLength=66) at cryptopp/cryptlib.cpp:781
#5 0x00002b1fdf8dcef9 in VerifyingKey_verify (self=0x5bab600, args=<value optimized out>, kwdict=<value optimized out>) at pycryptopp/publickey/rsamodule.cpp:77
#6 0x00000000004a290d in PyEval_EvalFrameEx ()
#7 0x00000000004a2e47 in PyEval_EvalFrameEx ()
#8 0x00000000004a40e0 in PyEval_EvalCodeEx ()
As you can see, this is pycryptopp-0.5.15 running, I will try to upgrade to see if the same bug also appears with 0.5.17. |
|||
| #33 | wontfix | implement Poly1305 or VMAC | zooko | |
| Description |
Poly1305 is a very fast and strong MAC designed by Prof. Dan Bernstein. You pair it with a cipher, and its security is proven on the assumption that the cipher is secure. I have a lot more confidence in the long-term security of Poly1305-XSalsa20 (or even in Poly1305-AES) than I do in HMAC-SHA256. Unfortunately Poly1305 isn't implemented in Crypto++. Wei Dai, the author of Crypto++, is also the author of VMAC, which is a competitor to Poly1305. VMAC is faster than Poly1305 per-byte on long messages, but it has a higher setup cost than Poly1305 has, so for short messages it is slower. On my old Pentium-M 1.86 GHz laptop Poly1305 took about 15,000 CPU cycles to setup and then MAC the first 64 bytes and VMAC took about 60,000 CPU cycles to do the same: http://osdir.com/ml/encryption.cryptopp/2008-02/msg00013.html Our current need for a MAC is solely for use in a KDF e.g. HKDF-Poly1305 where the inputs will be only a few tens of bytes, so the performance on short messages is more important. Also potential future uses of MACs would also probably most often be used on short messages. Also Poly1305 has more marketing power -- DJB pushes it (e.g. http://rdist.root.org/2009/07/14/nacl-djbs-new-crypto-library/ ). This means that over time Poly1305 is likely to get more peer-review and more independent re-implementation than VMAC. I asked Wei Dai if he would please implement Poly1305 in Crypto++, and his final answer was: http://www.mail-archive.com/cryptopp-users@googlegroups.com/msg04168.html , which I interpret as basically that he'd be willing to accept it and support it, but he doesn't want to spend the time to implement it himself. Now, it turns out that there doesn't exist a portable implementation of Poly1305! Here is the list of implementations, none of which we can just add into the pycryptopp source tree and have it automatically build on all of the platforms we support: http://cr.yp.to/mac.html The most portable one is the one built on OpenSSL and GMP: http://cr.yp.to/mac/test.html . It looks like it might be fairly straightforward to adapt this implementation by replacing OpenSSL and GMP with Crypto++. Replacing OpenSSL's AES with Crypto++'s AES should be trivial, but replacing GMP's math functions with Crypto++'s might be trickier. That "test.html" page that I referenced says "The system must have GMP 3 or later (for the mpz_tdiv_q_ui return value)". The source code -- http://cr.yp.to/mac/poly1305_gmp.c -- looks like mpz_tdiv_q_ui() plus a few simpler functions is all we need. Here is the GMP API doc for mpz_tdiv_q_ui(): http://gmplib.org/manual/Integer-Division.html#Integer-Division and here is the GMP API doc for the other functions: http://gmplib.org/manual/Integer-Arithmetic.html#Integer-Arithmetic . Here is the API doc for Crypto++'s integers: http://www.cryptopp.com/docs/ref/class_integer.html To close this ticket, either benchmark VMAC-XSalsa20 and Poly1305-XSalsa20 on a 32-bit ARM and convince us that the performance of VMAC-XSalsa20 is good enough or else port the http://cr.yp.to/mac/test.html implementation of Poly1305 to Crypto++'s integers from GMP and convince Wei Dai to accept your port into Crypto++. (Why 32-bit ARM? Because among the architectures that we care about, that's the one where performance matters most -- wasting CPU cycles on ARM is much more likely to noticeably reduce battery life than wasting wasting CPU cycles on amd64, and it is also more likely to force a human to wait.) |
|||
