#71 new enhancement

curve25519 wrapper

Reported by: xueyucoder Owned by: zooko
Priority: major Milestone:
Version: 0.5.19 Keywords: curve25519
Cc: zooko@… Launchpad Bug:

Description

python wrapper of D.J.Bernstein's curve25519 lib.

Attachments (1)

curve25519_1.darcs.patch (124.2 KB) - added by xueyumusic at 2011-03-24T12:00:22Z.
python wrapper on DJB's curve25519 lib

Download all attachments as: .zip

Change History (9)

Changed at 2011-03-24T12:00:22Z by xueyumusic

python wrapper on DJB's curve25519 lib

comment:1 Changed at 2011-03-24T12:15:02Z by xueyumusic

  1. I *temporarily* put all of the sources in a dir , compile them into curve25519.a when using "python setup.py *", and use the new generated lib directly.
  1. The python wrapper file is pycryptopp/publickey/curve25519module.cpp
  1. The test file is pycryptopp/test/test_curve25591.py, which uses the data from DJB's curve25519 sources.
  1. I use a shell script (create.sh) to create curve25519.a lib. The script will be executed when using "python setup.py build", however, when using "python setup.py test", it is also executed , which is not necessary.
  1. This patch need be reviewed and modified. It is just a could-be-run version..

comment:2 Changed at 2011-11-29T20:43:21Z by warner

Also see https://github.com/agl/curve25519-donna , which includes a python binding (that I wrote). The PublicKey/PrivateKey objects might make a nice API, or maybe there's some Crypto++ pattern that we should stick to. It's worth remembering that Curve25519 only offers DH key agreement (the output is a 256-bit shared random key). You can build public-key encryption on top of that, though (by creating a random keypair for each encryption, and including the public half along with the encrypted message, then discarding the private half).

comment:3 Changed at 2012-08-14T17:03:52Z by zooko

pycryptopp now includes Ed25519 signatures, but not yet public key encryption. I think I'd like to go ahead and incorporate curve25519 public key encryption eventually, but not soon.

comment:4 follow-up: Changed at 2012-08-14T18:01:54Z by davidsarah

The right way to construct a PK encryption scheme from the curve25519 key exchange is probably to use DHIES/ECIES.

comment:5 Changed at 2015-04-27T00:10:28Z by warner

  • Owner changed from zooko, xueyu to zooko

Reassigning to zooko, because the unusual comma-joined "zooko, xueyu" owner was confusing some tools I'm writing that try to identify all real users (by looking at the owners of tickets, among other things).

comment:6 follow-up: Changed at 2016-01-04T01:25:37Z by daira

Why have this in pycryptopp rather than using one of the existing libraries of Python bindings to libsodium or NaCl (
https://github.com/stef/pysodium or https://github.com/saltstack/libnacl or https://github.com/pyca/pynacl)?

Last edited at 2016-01-04T01:25:59Z by daira (previous) (diff)

comment:7 in reply to: ↑ 4 Changed at 2016-01-04T01:27:28Z by daira

Replying to davidsarah:

The right way to construct a PK encryption scheme from the curve25519 key exchange is probably to use DHIES/ECIES.

Or better, crypto_box_seal.

Last edited at 2016-01-04T01:27:45Z by daira (previous) (diff)

comment:8 in reply to: ↑ 6 Changed at 2016-01-04T01:41:23Z by daira

Replying to daira:

Why have this in pycryptopp rather than using one of the existing libraries of Python bindings to libsodium or NaCl (
https://github.com/stef/pysodium or https://github.com/saltstack/libnacl or https://github.com/pyca/pynacl)?

This comment also applies to #46, #91 and #94.

(To be fair, I'm not sure Python bindings existed when these tickets were opened. )

Version 0, edited at 2016-01-04T01:41:23Z by daira (next)
Note: See TracTickets for help on using tickets.