3 ms·

The linked repo is not a solution, single-file or otherwise. Speck is not only a weird and unusual block cipher to pick, it is more importantly only a block cip

by lvh 10y ago

The linked repo is not a solution, single-file or otherwise. Speck is not only a weird and unusual block cipher to pick, it is more importantly only a block cipher. It does not let you encrypt more than a block size at a time, and it does not give you authentication! Both of those things are anything but trivial. Furthermore, Speck has a variable block size between 32 and 128 bits. If you pick wrong, safe-looking things like CTR+HMAC-256 become unsafe (it's not hard to overflow a 32-bit counter).

pps43 10y ago
Well, it does Encrypt() and Decrypt(), which is what was asked. And it's not particularly difficult to pick 128 bit block size (after all, bigger is better). The problem is, it's not nearly enough to just do Encrypt() and Decrypt(). Only when you see that, the benefits of a real crypto library NaCL become apparent.
- lvh 10y ago
  It has things called "encrypt" and "decrypt", but it does not do anything a programmer could reasonably consider "encrypt" and "decrypt". If you don't authenticate your ciphertext, there's a decent chance your ciphertext won't remain secret. It doesn't give you an option for randomized encryption. Compare with Fernet: you get the same API, but you get to encrypt any message, and it's securely authenticated such that it stays secret. (secretbox is fine too; but it makes you pick a nonce). Additionally, "bigger is better" is not a reasonable way to pick primitives. Defaults matter. Perf matters. From experience and stats, people pick according those two vectors a lot more often than they pick along the "bigger is better" axis. When's the last time you saw an RSA-16384 signature? AES-256 might have twice as big a number as AES-128, but how much faith do you have in that extended key expansion? You use AES-128 a lot more often than you use AES-256, and you definitely use RSA-2048 a lot more often than RSA-16384. I don't think you can responsibly insist that this was an answer to the question. It is not a secure way to encrypt messages.

by lvh 10y ago

pps43 10y ago

Well, it does Encrypt() and Decrypt(), which is what was asked. And it's not particularly difficult to pick 128 bit block size (after all, bigger is better). The problem is, it's not nearly enough to just do Encrypt() and Decrypt(). Only when you see that, the benefits of a real crypto library NaCL become apparent.

lvh 10y ago
It has things called "encrypt" and "decrypt", but it does not do anything a programmer could reasonably consider "encrypt" and "decrypt". If you don't authenticate your ciphertext, there's a decent chance your ciphertext won't remain secret. It doesn't give you an option for randomized encryption. Compare with Fernet: you get the same API, but you get to encrypt any message, and it's securely authenticated such that it stays secret. (secretbox is fine too; but it makes you pick a nonce). Additionally, "bigger is better" is not a reasonable way to pick primitives. Defaults matter. Perf matters. From experience and stats, people pick according those two vectors a lot more often than they pick along the "bigger is better" axis. When's the last time you saw an RSA-16384 signature? AES-256 might have twice as big a number as AES-128, but how much faith do you have in that extended key expansion? You use AES-128 a lot more often than you use AES-256, and you definitely use RSA-2048 a lot more often than RSA-16384. I don't think you can responsibly insist that this was an answer to the question. It is not a secure way to encrypt messages.