Announcing TripleSec - JavaScript encryption combining Salsa20, AES, and 2fish

https://keybase.io/triplesec

by malgorithms • 13 years ago

23 22 13 years ago

keybase.io

maxtaco9• 13 years ago

Hi, Max here. I'm happy to answer questions about TripleSec, so let me know.

tptacek2• 13 years ago

Hi, Max. CTR doesn't have an IV. It has a nonce. IVs need to be unpredictable; nonces only need to not repeat.

maxtaco9• 13 years ago

It 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 :)

0xEA• 13 years ago

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

Perseids4• 13 years ago

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

maxtaco9• 13 years ago

Version 3, compatible with the latest test vectors published here: 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.

Perseids4• 13 years ago

Where can I download a pretty printed source? I was curious about your AES-CTR implementation.

maxtaco9• 13 years ago

It'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.ice...

jimrandomh• 13 years ago

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

maxtaco9• 13 years ago

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

ocfx• 13 years ago

I'm a security noob and I've been thinking about writing an encrypted chat application with Node.js and Socket.io. I have the chat part already done, but not exactly sure where to proceed with the encryption part. I don't want to store data and I want the data that is being received and sent to be encrypted. I was thinking of having users enter a room together with the same key to use for decryption. This could potentially be something I use and I was also considering using SJCL. Am I totally way off in my approach to this...? Suggestions?

crazygringo• 13 years ago

TripleSec seems to be only about the same person who did the encrypting, doing the decrypting -- for securing your own stuff, not really for communication. Communication requires exchanging keys beforehand...

[Edit: meant encrypting not encoding... thanks Perseids]

maxtaco9• 13 years ago

Agreed.

Perseids4• 13 years ago

I may be a bit pedantic, but please don't use "encode" when you mean "encrypt". These words describe two quite different concepts and guarantees. Exchanging them the other way around produces catastrophic results like "Of course we encrypt our passwords, we use the renowned base64".

maxtaco9• 13 years ago

SJCL is good software and has good defaults for its high-level encrypt function `sjcl.json.encrypt`. It uses CCM so you don't have to MAC in addition to encrypting (as TripleSec does). Depending on what parameters and degree of safety you want for PBKDF2, you might wind up locking up the browser while your keys are being derived. It's hard to speed up this part of the encryption process because it's meant to be intentionally slow to prevent password cracking.

The biggest problem you'll have in building a secure chat app is establishing the connection in the first place. To do that, either the participants will have to share a secret, or there will have to be some sort of public-key based handshakes with certified public keys.

Perseids4• 13 years ago

CCM is short for "Counter with CBC-MAC". I does also MAC the encrypted data and is equally slow as using a cipher and HMAC on top of it. A real speed improvement would be the Galois Counter Mode.

omtinez• 13 years ago

Generate a public/private pair of keys for each user in each chat, using user-provided entropy (key strokes, etc.). For each message sent, encrypt it using a random single-use key and encode the passphrase using the recipient's public key. Recipient can decrypt the message after it decodes the passphrase using his private key

genericacct• 13 years ago

It's all very cool but "magic bytes"? When I encrypt data the last thing i want is for its format to be easily recognizable.

maxtaco9• 13 years ago

That's a good point. You can feel free to strip them off. After byte 8, the rest of the outputs will appear almost entirely random. It depends on your usage. I'm imagining a database table on a server with a column of TripleSec-encrypted values. In that case, the adversary knows what he/she is getting by looking at the DB schema or reading the code.

Announcing TripleSec - JavaScript encryption combining Salsa20, AES, and 2fish

Related Stories