3 ms·
Hi, Max here. I'm happy to answer questions about TripleSec, so let me know.
by maxtaco 13y ago
Hi, Max here. I'm happy to answer questions about TripleSec, so let me know.
- tptacek 13y agoHi, Max. CTR doesn't have an IV. It has a nonce. IVs need to be unpredictable; nonces only need to not repeat.
- maxtaco 13y agoIt scares me to use something other than something random here because any scheme to remember which nonces you've used before seems bug-prone and vulnerable. As for whether it's called a nonce or IV, I've seen it written as both and IV is 3 characters shorter :)
- tptacek 13y agoNonces and IVs aren't the same thing. IV is not a shorter way to write "nonce".
- 0xEA 13y agoActually, you rarely want a predictable nonce as well. The difference is that a nonce must not repeat (or repetition is statistically irrelevant). Even per wikipedia, many often refer to an IV as a nonce: http://en.wikipedia.org/wiki/Cryptographic_nonce http://en.wikipedia.org/wiki/Cryptographic_nonce
- sdevlin 13y agoWhat problem does a predictable nonce cause?
- Perseids 13y agoHi! What version of Keccak do you use? Sha3 isn't standardized yet and it seems like they will be changing some details of the original proposition.
- maxtaco 13y agoVersion 3, compatible with the latest test vectors published here: http://keccak.noekeon.org/KeccakKAT-3.zip http://keccak.noekeon.org/KeccakKAT-3.zip . Our hope is that the algorithm won't change, but if it does, we'll bump version numbers and support decryptions with the old.
- Perseids 13y agoWhere can I download a pretty printed source? I was curious about your AES-CTR implementation.
- maxtaco 13y agoIt's all on GitHub. Please let me know of any bugs you find, and thanks. I did test the implementation against whatever test vectors I could find, but obviously carry code is tricky and error-prone. Link here: https://github.com/keybase/triplesec/blob/master/src/ctr.iced https://github.com/keybase/triplesec/blob/master/src/ctr.ice...
- jimrandomh 13y agoHi Max! Have you looked into taking the style of cipher-stacking you use for symmetric encryption, and applying it to key-stretching? For example, you might replace PBKDF2 with PBKDF2^bcrypt^scrypt. Similarly for public-key encryption: is there a good reason not to stack RSA and multiple elliptic curves? I personally think it's very unlikely that any of these algorithms have been broken, but it'd be a good way to restore some faith in cryptography, and introduce a safety factor.
- maxtaco 13y agoFor PBKDF2, we use SHA-512 XOR SHA3 as the inner PRF. But you're right, it would be interesting to stack bcrypt and scrypt too. That's a good idea in the name of maximum paranoia. My slight reservation here is that I haven't seen any published results on combinations of key stretchers (there are several for the other primitives). As for public key stacking, it depends on the application. The fear with putting encrypted data on a server is that it might sit there for all time and therefore needs to be present- and future-proof. If using public key for signatures, you can plan ahead for your key's expiration. For public key encryption, maybe stacking is the right idea.