5 ms·

I like such tiny projects: you can drop .c and .h into your own project and have something useful ready-to-use. Thanks for sharing! For those asking, this is wh

by dchest 10y ago

I like such tiny projects: you can drop .c and .h into your own project and have something useful ready-to-use. Thanks for sharing! For those asking, this is what distinguishes it from libsodium. Compared to NaCl or TweetNaCl, it has password hashing (Argon2), although, to be fair, I wouldn't recommend using non-optimized implementation of it, like in this library, for serious stuff. Some notes: - Let's call Ed25519 with BLAKE2b something like "Ed25519-BLAKE2b" to avoid confusion. - crypto_chacha20_random is a confusing name, I'd prefer crypto_chacha20_stream - Everyone uses "crypto_" for namespacing their libraries nowadays! Let's use something else to avoid collusions :)

tptacek 10y ago
So, minus the thing you don't recommend people use, there is no advantage to this over TweetNacl?
- dchest 10y ago
  Even worse: users of TweetNaCl can easily switch over to the real deal (performance-wise) — NaCl or libsodium — without changing anything, while with this library they'll have to grab pieces of optimized code from various sources, and then dig into insides Ed25519 implementation to replace SHA-512 with BLAKE2b. Unless the author implements an optimized version of Monocypher, of course.
  - loup-vaillant 10y ago
    > Unless the author implements an optimized version of Monocypher, of course. We may be able to compete with ref10 without too much code. I haven't found a way yet (very frustrating). In the mean time, you have the Donna implementation, which can be used with any hash (it's a compilation option).
loup-vaillant 10y ago
- Naming Ed25519 is not obvious: I do provide SHA-512 as an option. - I'll consider crypto_chacha20_stream - I'll stick with "crypto_", for 2 reason. First, you only need one crypto library. Second, a brutal search & replace will let you use another namespace in 30 seconds. Maybe I should provide a script to do that?
- pouta 10y ago
  Definitely. This a quick and easy +1
- e12e 10y ago
  > I do provide SHA-512 as an option. Why? If the goal is compact, easier to deploy - why have choice at all? [ed: I just saw this on the homepage: Note the presence of SHA-512 in a separate compilation unit. It is meant to test ed25519 with the test vectors I got from the RFC. In production, most users will be expected to use Blake2b —the default setting.] I also wonder a bit on the naming - using algorithm over intent (sha512 vs "hash") - I can see why transparent naming is good - on the other hand, wouldn't the easiest approach be: use some sort of framing (monochypher_v1) and pair that with primitives that "do the right thing"? I suppose one could use monochypher as a provider and another "interface" library as a consumer - might make for easier auditing and development. But now you need two header/c files, and they have to stay in sync in order to be reviewed in pairs (to avoid subtle bugs in key handling and such?). Which brings us back to: in five years, when a developer needs to update their simple utility that uses monochypher - will that developer have to consider changing cryptographic primitives, moving users from one generation of ciphers to another - or will monochypher handle that?
  - loup-vaillant 10y ago
    (I spelled it "Monocypher", without the first "h".) I need SHA-512 for tests. The only test vectors I could find were for the official ed25519, with SHA-512. The option is there anyway, I might as well provide it. I do transparent naming because the choice of primitive has user visible effects. If I have the SHA-512 of some file, I can't just use Blake2b to check that hash. Same for encryption and authentication: changing them is transparent only for transient messages. Encrypted files won't convert themselves to the new encryption scheme, and neither will the authentication tags. Same thing for long term secret/public key pairs. That said, the high level constructions don't mention the primitives. They're all called "crypto_lock" or something. Long term, changes are not expected to be transparent. The only backward compatible path is to stick to the older version of Monocypher. Any transition will need to be handled explicitly. I think that's okay, because I don't think I'll need to make breaking changes often. I expect a stable version to last at least 5 years, possibly 15. Then the next version will break everything, and users will just have to cope, most probably by supporting both v1.0 and v2.0 for a time. Hopefully that won't be too hard, given the small size of the library.

by dchest 10y ago

tptacek 10y ago

So, minus the thing you don't recommend people use, there is no advantage to this over TweetNacl?

dchest 10y ago
Even worse: users of TweetNaCl can easily switch over to the real deal (performance-wise) — NaCl or libsodium — without changing anything, while with this library they'll have to grab pieces of optimized code from various sources, and then dig into insides Ed25519 implementation to replace SHA-512 with BLAKE2b. Unless the author implements an optimized version of Monocypher, of course.
- loup-vaillant 10y ago
  > Unless the author implements an optimized version of Monocypher, of course. We may be able to compete with ref10 without too much code. I haven't found a way yet (very frustrating). In the mean time, you have the Donna implementation, which can be used with any hash (it's a compilation option).

loup-vaillant 10y ago

- Naming Ed25519 is not obvious: I do provide SHA-512 as an option. - I'll consider crypto_chacha20_stream - I'll stick with "crypto_", for 2 reason. First, you only need one crypto library. Second, a brutal search & replace will let you use another namespace in 30 seconds. Maybe I should provide a script to do that?

pouta 10y ago
Definitely. This a quick and easy +1
e12e 10y ago
> I do provide SHA-512 as an option. Why? If the goal is compact, easier to deploy - why have choice at all? [ed: I just saw this on the homepage: Note the presence of SHA-512 in a separate compilation unit. It is meant to test ed25519 with the test vectors I got from the RFC. In production, most users will be expected to use Blake2b —the default setting.] I also wonder a bit on the naming - using algorithm over intent (sha512 vs "hash") - I can see why transparent naming is good - on the other hand, wouldn't the easiest approach be: use some sort of framing (monochypher_v1) and pair that with primitives that "do the right thing"? I suppose one could use monochypher as a provider and another "interface" library as a consumer - might make for easier auditing and development. But now you need two header/c files, and they have to stay in sync in order to be reviewed in pairs (to avoid subtle bugs in key handling and such?). Which brings us back to: in five years, when a developer needs to update their simple utility that uses monochypher - will that developer have to consider changing cryptographic primitives, moving users from one generation of ciphers to another - or will monochypher handle that?
- loup-vaillant 10y ago
  (I spelled it "Monocypher", without the first "h".) I need SHA-512 for tests. The only test vectors I could find were for the official ed25519, with SHA-512. The option is there anyway, I might as well provide it. I do transparent naming because the choice of primitive has user visible effects. If I have the SHA-512 of some file, I can't just use Blake2b to check that hash. Same for encryption and authentication: changing them is transparent only for transient messages. Encrypted files won't convert themselves to the new encryption scheme, and neither will the authentication tags. Same thing for long term secret/public key pairs. That said, the high level constructions don't mention the primitives. They're all called "crypto_lock" or something. Long term, changes are not expected to be transparent. The only backward compatible path is to stick to the older version of Monocypher. Any transition will need to be handled explicitly. I think that's okay, because I don't think I'll need to make breaking changes often. I expect a stable version to last at least 5 years, possibly 15. Then the next version will break everything, and users will just have to cope, most probably by supporting both v1.0 and v2.0 for a time. Hopefully that won't be too hard, given the small size of the library.