nim-lang / needed-libraries

This repository contains a list a needed libraries.
112 stars 5 forks source link

Cryptography support #100

Open DonaldTsang opened 5 years ago

DonaldTsang commented 5 years ago

This is an exhaustive list, not everything is needed

  1. All hash functions in https://github.com/coruus/sphlib (SHA3 candidates)
  2. All finalists hash functions in https://github.com/bsdphk/PHC (password derivation functions)
  3. AES, serpent, Twofish, RC6, MARS (AES candidates) + Camellia, SEED and ARIA
  4. All Phase 3 ciphers in the eSTREAM portfolio https://en.wikipedia.org/wiki/ESTREAM
  5. All Block cipher modes like in https://web.archive.org/web/20170904011624/http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
DonaldTsang commented 5 years ago

Other ways of comparing notes would be to have the ciphers, hashes and modes of https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries

zah commented 5 years ago

Nimcrypto covers a lot of these: https://github.com/cheatfate/nimcrypto

DonaldTsang commented 5 years ago

@zah that only scratches the surface when compared to the the list, which has ~100 items

FedericoCeratto commented 5 years ago

Please be mindful of the security risks of implementing cryptographic functions. I'm wrapping libsodium for this reason: https://github.com/FedericoCeratto/nim-libsodium

DonaldTsang commented 5 years ago

@FedericoCeratto for the common cryptographic functions, sure. But for the other less used and "experimental" ones? I wouldn't mind weaker implementations.

snej commented 4 years ago

This feels more like a bucket-list, i.e. exhaustive, than needed. I’ve been using crypto for a long time and never needed more than a small number of algorithms like SHA, MD5, AES, RSA, xx25519, Blake2b, ChaCha.

The trend in modern crypto libraries is curation and higher-level operations, not a huge set of primitives. No one but a crypto researcher needs access to 50 different symmetric stream ciphers. (And if you do, the C APIs for crypto functions are ridiculously simple, so they’re very easy to Nim-wrap yourself.)

the other less used and "experimental" ones? I wouldn't mind weaker implementations.

A weak implementation of a crypto primitive is actively dangerous, unless you’re just using it for research. Doesn’t seem like something that should be in a library, where someone could find it without being aware of the danger.

mratsim commented 4 years ago

Agree with @snej I'd rather have a couple of primitives that are widely used, well implemented, well optimized and audited than a collection that gathers dust.

For example the only SHA3 candidates that actually see widespread use are SHA3, Keccak and BLAKE2.

Now regarding cryptography support, do not that we are in the middle of a security audit at Status and the following primitives are went under review:

Also as a side project I'm implementing a comprehensive library for pairing-based cryptography and zero-knowledge proofs: https://github.com/mratsim/constantine