In the Dev update I saw a reference to NACL, my guess is that you are refering to DJ Bernsteins NACL libs at http://nacl.cr.yp.to/
I was wondering if NACL is a component used in maidsafe and if so, how and where?
Also, what encryption routines do you use from NACL because only AES and SHA make sense because of it’s support in modern CPU’s. If you would use Salsa, curve and/or poly, encryption would not be able to be offloaded to the CPU and any small farming rig will grind to a halt. Correct?
I am learning as I go so please correct me if I am wrong
np, the Ed25519 curve analysis so far puts the EC vs RSA technology in salt at several hundred times speed improvements (sign 160,000 keys per second as opposed to just around 100 with RSA 4096.). RSA is being caught up by maths quickly these days, discreet maths is a fast moving field.
AES ctr (authenticated) is also included. Salsa is considerably faster though, even Nacl implementation of AES128 ctr is around twice the speed of cryptopp in this case (see SUPERCOP benchmarks for much of this).
CPU’s handle AES ni and SHA256 (not 512) hashing very quickly these days. Many of the libs make use of this, but timing attacks etc. mean some libs will actually implement constant time primitives to avoid side attacks. It’s an enormous area that I think even a career in will not avoid error. At least Nacl has a decent vision, to make it hard to get wrong and that seems to work quite nicely.
In terms of hash, then it’s not encryption but always gets lumped in there for some reason (it’s very handy). SHA II hashes are pretty simple and generally implemented via dictionaries. SHA III or even blake II is probably a bettter choice in the very near future. So SHA256 may be fast in cpu’s but is getting old now (extension attacks, lack of sponginess etc.)
These days crypto is such a vital area we need all the expertise we can and the reason for Nacl is to improve upon that. IT’s still being tested by us though.
Motivation - speed, efficiency and allow farming on much smaller devices
Not as aware of xAES, NTRU is extremely interesting though, I have been watching that one pretty closely. Very interesting simple and fast. I like the approach they are taking with it’s development. It’s a tough area, I always thought we would jump passed EC and straight to lattice, but there are to many breaks there for now (well signatures etc.). We don’t pay these maths researchers enough for my liking, their work is too important for government funding.
Thanks for the elaborate reply but does it mean NACL is now already integrated/used in MaidSafe or are you just researching it’s purposes for further use?
Afaik and can substract from the docs most of the encryption/hashing in the current version is still AES and SHA-256? Is this correct?
Hi, just wanted to know whether there’s any update concerning baking NTRU into the encryption process ? It’s supposed to be PQ computer safe, but hasn’t found any significant echo yet in real world applications that are easy to use. The only app I know of is Goldbug which is not very userfriendly
Not yet, it is only signing that we would be concerned about really. So NTRUSign but this still has some issues AFAIK. We are putting much of that behind a trait in the code, meaning we can swap over easily, however upgrading after release would be more difficult. Well worth prodding this one every so often.
