3 ms·

- 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, y

- 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.

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.