391–400 of 409 posts
So where is the Mono / C# wrapper, or C# implementation of this? (:
https://github.com/konovod/monocypher.cr
I think I will personally do C++, OCaml, and perhaps Lua. For the rest, either someone contributes, or you'll have to look at the FFI yourself…
I thought the first rule of crypto was never role your own crypto.
Seriously though, Monocypher is getting getting past the "own crypto" stage at this point.
Have the library functions been tested (or proved) to be constant time ? This is a critical property of libsodium. Another question is what make the difference in number of line of codes with libsodium ? I mean what do these lines of of libsodium that your lib doesn't have contain ? Also, is this a fair metric ? You know we can have 1000 char long lines in C. ;)
Just check the absence of secret dependent branches, and secret dependent array indices, it's pretty simple.
> what make the difference in number of line of codes with libsodium ?
Less lines means less need for eyeballs, tests, and audits. Libraries the size of TweetNaCl (and, to a lesser extent, Monocypher), can be subjected to very rigorous audits, and increase confidence accordingly.
> what do these lines of of libsodium that your lib doesn't have contain ?
I can see 3 sources: redundant primitives (Monocypher is not redundant), alternate implementation (Monocypher sticks to portable C), and verbose implementations (Monocypher keeps it simple).
> Also, is this a fair metric ?
Not quite: I did not count the size of the header in Monocypher and TweetNaCl. Still, I don't think Libsodium has less than 22K lines of actual code. (Note: I counted everything with sloccount)
On the other hand, my lines never exceed 80 characters.
Earlier quoted context omitted.
Yes, but home-built airplanes come with all kinds of limitations that are, to continue the analogy, more like "can't use commercially ever, and any use for non-commercial purposes requires a big disclaimer on every message sent. http://www.odtug.com/media/tvzzjjck.jpg My use of commercial aviation in the GP was quite intentional, btw.
Yes, but 1) those are government regulations, not a community policy. As a community aviation is much more welcoming of newcomers than crypto, and in the case of crypto this attitude is entirely community-driven, since crypto is not regulated the way aviation is. And 2) homebrew is often a stepping stone towards professionalism in many fields. But the crypto community actively discourages homebrew with its "Don't bui…
They know that someone's backyard airplane isn't ever going to be used commercially without certification, and even if it were the entire world's aviation fleet isn't going to start using that model overnight, as might happen with some homebrew crypto and a popular new app. So the situation is entirely unanalogous.
Earlier quoted context omitted.
Yes, but 1) those are government regulations, not a community policy. As a community aviation is much more welcoming of newcomers than crypto, and in the case of crypto this attitude is entirely community-driven, since crypto is not regulated the way aviation is. And 2) homebrew is often a stepping stone towards professionalism in many fields. But the crypto community actively discourages homebrew with its "Don't bui…
You can't view community policy and government regulation as two unrelated things. The aviation community has a more welcoming attitude because of government regulation. They know that someone's backyard airplane isn't ever going to be used commercially without certification, and even if it were the entire world's aviation fleet isn't going to start using that model overnight, as might happen with some homebrew crypt…
Earlier quoted context omitted.
You wouldn't want true random numbers anyways. If you're encrypting it, then you'll want to decrypt it later. That means you'll need the random data you used again. If you had a secure channel over which to send or store the random data, then you could just use that channel to send or store the plaintext itself (note that the random data will be the same length as the plaintext). Such a system could only be useful if…
I think you missed the point of the comment, which wasn't about physical possession of a computer. You also make assumptions, such as chips being inside the computer, when they can in fact be in an outside environment-based RNG. The hairdryer example is the canonical and prototypical weakness in that particular type of "rng". I'll try to be explicit about that in the future.
Earlier quoted context omitted.
> How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Sounds fascinating. Can you please tell us more?
If you had a RNG that sampled some hardware noise but then you altered the environment by introducing extreme temperatures, maybe the RNG would end up with biased output. A simple example: you can use a camera as a good source of randomness, even taking a picture of a wall indoors. But if an attacker was able to flood that room with light and overwhelm your sensor, he could predict the image would be 100% white pixel…
Earlier quoted context omitted.
Just because an AES implementation matches the test vectors does not make it correct or safe. Here is an excellent visual depiction of several different AES implementations, many of which do not run in constant time: https://cr.yp.to/mac/variability1.html Implementing AES with variable time secret-dependent operations can leak the key. There are much bigger and more terrifying subtleties to implementing crypto correc…
> "Just because an AES implementation matches the test vectors does not make it correct or safe." Actually, this does make it correct. Whether or not it is safe depends on the application. For example, I sent my friend Bob some cyphertext that I calculated by hand with a pencil and paper using the AES algorithm. I sent it via my trusted courier Eve. It took four hours for me to do the calculation. At the last minute…
Earlier quoted context omitted.
Just because an AES implementation matches the test vectors does not make it correct or safe. Here is an excellent visual depiction of several different AES implementations, many of which do not run in constant time: https://cr.yp.to/mac/variability1.html Implementing AES with variable time secret-dependent operations can leak the key. There are much bigger and more terrifying subtleties to implementing crypto correc…
> "Just because an AES implementation matches the test vectors does not make it correct or safe." Actually, this does make it correct. Whether or not it is safe depends on the application. For example, I sent my friend Bob some cyphertext that I calculated by hand with a pencil and paper using the AES algorithm. I sent it via my trusted courier Eve. It took four hours for me to do the calculation. At the last minute…
Whenever I feel the need for a tin foil hat I start to wonder if there is a FUD campaign powered by the "establishment" to encourage people not to investigate this area of computer science so that security holes will remain unnoticed. But, yes I wouldn't start out on writing a crypto library, then again I wouldn't attempt to build an OS or a 3D stack or even an web server either. All cases where a security breach cou…
Writing your own crypto is the only way to become good at it, or to understand more about crypto. * DJB wrote NaCl * Frank wrote libsodium / libHydrogen * Brian wrote Ring * Thai Duong and Bleichenbacher wrote Tink * Eric Young wrote OpenSSL * Jason Donenfeld wrote Wireguard * Shoup wrote NTL * Emily Stark, Mike Hamburg and Dan Boneh wrote SJCL * Thomas Pornin wrote 6 SSL libraries and then BearSSL * Adam Langley wro…
NaCl does not use autoconf nor even make.
It is not necessary but if someone really feels compelled to use it, why stop them?
I have never seen any author or end user comment that they dislike using autoconf, or write alternatives to it. Autoconf is loved by all, isn't it?
I think what you could say is that using NaCl in your own software is the only way to get good at using it. Maybe the existence of libsodium means that more developers will have a go at using NaCl? Is it easier to use than an SSL library? The only way to find out is to try both and compare.
There is no need to use autoconf to build libnacl.a. The original build system for NaCl is beautifully simple. But if someone misses autoconf and make, then libsodium has added in those dependencies.
More projects using NaCl:
As far as I can tell, the authors listed on the above site are not "rolling their own crypto" for their projects, they are using cryptography written by the author of NaCl.
Personal bias disclosure: I find NaCl easier to use than all the SSL libraries I have tried. If I am not mistaken, I believe this was a design goal by the author.