nmadden

15 ms·

91.
by nmadden 3y ago
Those RFCs don’t replace 7519, they are extensions and best practices. “Jot” is still indeed the intended pronunciation, whether you like it or not.
92.
by nmadden 3y ago
Yes, it became part of the standard in rev 2. 3DES will be completely forbidden for federal use after the end of the year. Sweet32 was a demo, attacks get better. And there are other generic attacks against overuse of 64-bit blockciphers. O
93.
by nmadden 3y ago
> IDEA and 3DES for example are perfectly secure for that usage. I wouldn’t use the phrase “perfectly secure”. They are both 64-bit block ciphers so vulnerable to generic collision attacks like https://sweet32.info/ . Thi
94.
by nmadden 3y ago
It is useful, but it also has weaknesses. For example, I’ve lost count of the number of times I’ve seen someone forget to close() an IO-based stream (eg File.lines). But probably for 99% of cases you could get away with slurping the entire
95.
by nmadden 3y ago
Indeed, and some things become really hard to write because the operations are required to cope with parallel execution that I never want. Anyone doing serious parallelism is going to reach for another library anyway (Rx etc). Making stream
96.
by nmadden 3y ago
Yeah, and that’s totally reasonable. I’m one of those people that thinks signatures should be used for software updates and nothing else though.
97.
by nmadden 3y ago
> cofactors might be less important when we lack complete additional formulae for a Weierstrass curves, which makes them hard to implement in constant time, but much more important once we do (as is the case now). If I remember correctly
98.
by nmadden 3y ago
Thanks for these helpful links. Looking at the Mozilla examples in mobile Safari just now and the MathML rendering is pretty dreadful for almost all of them. It looks like there is still a long way to go.
99.
by nmadden 3y ago
It’s possible that in the specific sense that NIST defined, KYBER-512 isn’t as strong as AES-128. However, that doesn’t mean that it’s less secure in general. E.g. DJB himself wrote a good article[1] on how even though 128-bit AES and 256-b
100.
by nmadden 3y ago
I’ve not followed the PQC competition very closely, but I don’t think djb’s arguments significantly impact whether you should use KYBER-512. From my reading, as someone with a decent amount of crypto knowledge, all the evidence suggests tha
101.
by nmadden 3y ago
It can be scalable if you’re prepared to chuck enough money at it. (Response time latencies are another matter, but that is somewhat less important in email). I have no experience at all of securing production mail servers, so whether they
102.
by nmadden 3y ago
The PKCS#11 standard, which is implemented by most HSMs defines two attributes that control this: - Marking a key as “sensitive” means that the raw key material cannot be exported, except in encrypted (“wrapped”) form. Such an encrypted key
103.
by nmadden 3y ago
That’s not necessarily true. You can cluster and replicate HSMs to provide scalability but it is common practice to forbid extraction of private key material. In many cases you can’t change that setting without a complete reset of the devic
104.
by nmadden 3y ago
I did wonder about that when I read it. The idea of changesets and versions sounds an awful lot like branches and commits.
105.
by nmadden 3y ago
Quibble: Half of 2^256 is 2^255. Grover’s algorithm “square-roots” the search space.
106.
by nmadden 3y ago
JDBI3 looks nice. I previously had good experiences with Dalesbred ( https://dalesbred.org ), which sounds similar to JDBI3's fluent API -- a fairly minimal layer over JDBC with better ergonomics.
107.
by nmadden 3y ago
Comparing GCM to CBC+HMAC is not fruitful because they are different in too many aspects. I already stated in the very first message in this thread that HMAC is far more robust than GMAC. Compare CTR+HMAC vs CBC+HMAC. What I take issue with
108.
by nmadden 3y ago
You previously said CTR mode nonce repetitions are “always bad” and are “game-over”. I provided a simple counterexample. You also said that IV reuse in CBC mode can only be exploited if you setup an ECB-style attack. Also untrue. Now you ha
109.
by nmadden 3y ago
There are several reasons. Off the top of my head: 1. People use bad PRNGs or otherwise mess this up so the nonces aren’t as random as they should be, or they use ciphers with small nonce spaces (eg original ChaCha with 64-bit nonces) and g
110.
by nmadden 3y ago
> whereas I can’t think of an instance where a repeated CTR nonce wasn’t game-over. The fact that you can’t think of an example is not a serious security argument. This is why we have rigorous security definitions rather than hand waving
111.
by nmadden 3y ago
That’s not true. CBC mode with a repeated IV immediately reveals equality of plaintexts or any common prefix (modulo block size).
112.
by nmadden 3y ago
But it’s less bad because of HMAC, not because of CBC. Hand waving arguments that CBC is meaningfully better than CTR mode under IV reuse are silly. There are cases where a nonce reuse in CTR mode reveals very little (eg key wrapping) and c
113.
by nmadden 3y ago
Like much of Peter Gutmann’s writing this is a mixture of good points and things that are downright incorrect or at least misleading. For example, he criticises GCM for losing confidentiality when a nonce is reused. True, but ChaPoly has ex
114.
by nmadden 3y ago
> Simply getting a couple of random messages with the same nonce is NOT enough. Yes it is. You simply XOR the two auth tags and then compute the roots of the resulting polynomial (with known coefficients). There typically aren’t that man
115.
by nmadden 3y ago
Say what now? GCM is itself vulnerable to CCA in a nonce reuse scenario - exactly the subject of this thread. Not to mention padding oracle attacks against CBC mode etc. Almost all modern symmetric ciphers achieve CCA security by combining
116.
by nmadden 3y ago
Or better yet: https://neilmadden.blog/2021/10/27/multiple-input-macs/
117.
by nmadden 3y ago
Really pedantic nit here, but the cipher Salsa20 is called “Salsa20” and so reduced round versions are called e.g. “Salsa20/8”. However the ChaCha cipher is just called “ChaCha” so the specific-round versions are just “ChaCha20” or “Ch
118.
by nmadden 3y ago
Right, and 128 bits is way better than 96. The only thing to potentially be aware of is that the randomized block counter may end up overflowing if it happens to end up with a large initial value (or you encrypt large messages). That sho
119.
by nmadden 3y ago
Message forgery does quite often lead to decryption actually - google “chosen ciphertext attack”.
120.
by nmadden 3y ago
If you are using random nonces, segregating the nonce space to have a dedicated 32-bit block counter yields worse security bounds anyway. The whole point of that segregation is to avoid collisions when using a deterministic nonce like a cou

More ›