Hackage :: [Package]

eccrypto: Elliptic Curve Cryptography for Haskell

[ bsd3, cryptography, library ] [ Propose Tags ]

Elliptic Curve Cryptography in Haskell, evolved for correctness and practical usability from higher-level libraries.

The implementation is pure Haskell and as generic and fast as reasonably possible. Timing-attack resistance is important, failure must be documented.

This library was formerly known and its code originated as hecc, but since this would imply Hyperelliptic ECC, the name was changed.

Also the scope was changed by selecting best internal formats and no longer trying to be overly general, allowing more optimizations.

N.B.: F2 is faulty and slow.

More secure curves will be added.

[Skip to Readme]
Versions 0.0, 0.0.1
Dependencies base (==4.*), bytestring (==0.10.*), cereal (>=0.4 && <0.6), crypto-api (==0.13.*), SHA (>=1.6.4 && <1.7), vector (>=0.10 && <0.12) [details]
License BSD-3-Clause
Copyright (c) Marcel Fourné, 2009-2016
Author Marcel Fourné
Maintainer Marcel Fourné (haskell@marcelfourne.de)
Category Cryptography
Source repo head: git clone https://github.com/mfourne/eccrypto.git
Uploaded by MarcelFourne at Wed Jun 15 07:41:40 UTC 2016
Distributions NixOS:0.0.1
Downloads 489 total (10 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2016-06-15 [all 1 reports]
Hackage Matrix CI

Modules

[Index]

Downloads

Maintainer's Corner

For package maintainers and hackage trustees

Readme for eccrypto-0.0.1

[back to package description] 
ECC
---
RSA just doesn't cut it anymore for fast public-key crypto. Keys are large for reasonable security making it quite slow...
Enter elliptic curves: smaller numbers are necessary and everything is faster. Maybe this library is not for embedded system usage, but now people can experiment with ECC for those use-cases where some form of RSA would be chosen otherwise.


Timing Attack Resistance
------------------------
The point multiplication uses the montgomery ladder algorithm which should be timing attack resistant, but when mul by a number in binary form 1000..0 the operation gets strangely fast (us instead of ms) and 1000..0001 it is strangely slow (1.5 times), which hints to something fishy going on. More research will follow, but sidechannel-resistance is not totally out-of-focus. 
Testing has given me the idea that the following-zeroes-case massively benefits from branch-prediction and the trailing-one-case throws it totally off (will have to check that on other CPUs). "More natural" numbers are safer (tested), but I wouldn't dare to say that the matter is resolved.
P.S.: 2^N-1 does not show the cache-problem, only long rows of zeroes.


Motivation
----------
This is a side-project from which other people may benefit. Due to time-constraints, I can't work as much on it as I would like. If you use/like it or want to make some criticism heard, please write me an email.