opensse / crypto-tk Goto Github PK

In the current version, set hashing (aka incremental hashing) is implemented using Jeremy Maitin-Shepard's ecmh code.
To reduce the code base (and hence the attack surface), and as libsodium now implements Elligator2 (cf. jedisct1/libsodium/issues/628, although we might need to wait for v1.0.16 to get a stable version), switch to Elligator2 for the implementation of this feature.

Performance might suffer a bit from this update (the random string-to-curve point function will most probably be faster on GLS254 than on Curve25519 as the former is a binary curve). Security should increase though (as GLS254 is indeed a binary curve, which is not great given the advances of the algorithms solving the discrete log in small characteristic).

For now, the only way to compute a hash in crypto-tk is to give the input at once. This is an issue when we want to compute the hash of a concatenation as we have to put all the data in a single buffer before hashing.

Creating these buffers causes both efficiency and security problems (e.g. in the HMac implementation).

No documentation is provided for the APIs of the crypto-tk library.
Add doxygen-formated comments (at least to) the public headers, and add Sconstruct targets that generate this documentation.

Restrict to API documentation. How cryptographic primitives are instantiated and implemented will be described on the OpenSSE website.

Although keys can be safely generated inside the library, they cannot be extracted (this is done on purpose), and hence cannot be stored. This is a problem when building real applications that need to be shut down and later restarted.

We must implement a way to store the keys in a file/stream that can be safely exposed. This in particular means encrypting this stream using authenticated encryption, with a key derived from a password.

The AEZ implementation, which is indeed the reference implementation of AEZ, uses AES instructions to compute the AES round function, making the code not portable (although both AES-NI and NEON instructions are supported).

Replace calls to the AES primitive (even pruned ones) by calls to an already implemented primitive in libsodium. These include Blake2b and ChaCha20, although directly using ChaCha20 might be hard. Full Blake2b would be a very secure (quite inefficient) choice.

/crypto-tk/tests/CmakeLists.txt modify line 27 add sse_cryto,delete OpenSSE::crypto-tk,add pthread(install it)
/crypto-tk/CmakeLists.txt delete line 124,125
and pthread is needed，and libsodium-1.0.18，gmp-6.0.0a specificly
if possible，i think it would be better run on the Mac OS rather than ubuntu

The memory locking on cryptographic keys (through libsodium) is not thread safe, making it hard to use on real use cases, without cheating (ie. copying the buffers meant to initialize keys).

We should implement a fix that is efficient: relying on locks seams too expensive, lock-free mechanisms seem necessary, yet not trivial to implement.

The compilation raises many warnings. We should try to fix them.
We might have to silence some of them for some dependencies (e.g. Google Test).

Specify a coding style, as well as tools to enforce it (e.g. clang-format).

The existing codebase will probably not satisfy the chosen rules, and will need some reformatting work.

Coverity is a static analysis tool dedicated to finding security vulnerabilities.
Create a dedicated branch that will be used by coverity to analyse the code.

Although range-constrained PRF are used in the OpenSSE schemes implementations, they are not implemented inside the cryptographic toolkit, but on top of it.

Integration of this primitive would be a security and performance benefit (e.g. through the direct use of the Key template to manage intermediate nodes).

Now that libsodium is used in the cryptographic toolkit since the merge of PR #3, we should try to remove all the dependencies to OpenSSL. Also, OpenSSL is actually terrible so it is not a bad idea in terms of security.

For symmetric key primitives, we can directly use libsodium's API. For asymmetric crypto, there are two primitives, trapdoor permutations and incremental hashing.

For TDP, we can embed mbedTLS' implementation. For elliptic curve multiset hash, we will have to wait for the implementation of Elligator2 in libsodium (cf. jedisct1/libsodium#628).