TripleSec – Symmetric Encryption in the Browser Combining AES, Salsa20, Twofish

https://keybase.io/triplesec/

by jessaustin • 11 years ago

41 47 11 years ago

keybase.io

istvan__3• 11 years ago

Somebody from the security community could shed some light on why this is a good/bad idea.

gruez• 11 years ago

something something roll your own crypto [1]

[1] https://security.stackexchange.com/questions/18197/why-shoul...

sarciszewski3• 11 years ago

See this instead: http://www.cryptofails.com/post/75204435608/write-crypto-cod...

michaelsbradley• 11 years ago

With respect to the browser, What’s wrong with in-browser cryptography?[1] and Javascript Cryptography Considered Harmful[2] may still be relevant.

[1] http://tonyarcieri.com/whats-wrong-with-webcrypto

[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

explorigin2• 11 years ago

Both of the articles have some flaws (that Matasano one is really bad/dated actually).

Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...

istvan__3• 11 years ago

This is really good.

I am curious if somebody could mitm the https layer with rogue ca and append more JS to the content. The problem I see as a non-expert with dynamic content that it can't be signed. If we use HTTP as it was intended we could just name the content after the sha(content). That way the client could validate the integrity. The problem with shipping computation to the client side that you lost the integrity verification and opened up the platform to all sorts of vulnerabilities. I guess we should just create a brand new protocol that supports stateful clients, it is network efficient and security is part of the design.

lewisl9029• 11 years ago

Thanks for sharing.

I've come across the Matasano one before and felt it might have been a bit outdated in light of recent efforts with WebCrypto. So it was interesting to see an article critiquing WebCrypto for once.

I'm interested in hearing some thoughts on how well WebCrypto would hold up in a local execution environment like Cordova/nw.js/electron rather than in the browser. It seems to me that many of the article's concerns can be addressed by providing the application code in a verifiable package rather than grabbing it over the browser ad-hoc. Am I missing anything?

jpalomaki• 11 years ago

A good blog entry on the topic:

http://blog.cryptographyengineering.com/2012/02/multiple-enc...

tyho• 11 years ago

If you are going to the trouble of layering encryption like that you may as well using a MAC with similar construction. It is poorly thought out. I would also be much more worried about scrypt than AES in the future, it has had much less review yet is not layered in the same way.

Also the go reference implementation is not idiomatic, It does not conform to the interface of other encryption functions in the standard library.

EDIT: I was wrong, they do double up on MAC's but do not on the KDF.

Mutjake• 11 years ago

Roughly the upside is that (in theory) the attacker needs to defeat each cipher separately (barring that the combination offers some shortcuts where one cipher interacts with another so that some computational complexity can be eliminated). Downside is that the performance takes a hit (processor/bandwidth [if blocksizes don't match, dunno if this is an existing risk]), which might not be trivial.

Disclaimer: I assume that existing, proven implementations are used and out from one cipher is handed over to another as input, keys and IVs and other crypto mumbo jumbo are not recycled and that the implementation does not offer new side-channel attacks somehow etc etc.

Personally I'd wait for a while to allow more competent people to analyze the library. In the meanwhile one can do performance profiling to roughly calculate how much beefier servers are needed in a real-world scenario due to extra crypting and decrypting :-)

istvan__3• 11 years ago

Thanks everybody, much value as usual!

mangeletti7• 11 years ago

In my opinion, Keybase needs a Warrant Canary on their website.

See https://canarywatch.org/faq.html for more information.

akerl_3• 11 years ago

I'm waiting for the first publicly released case against warrant canaries. From everything I've seen, and based on the site you linked as well, they're essentially untested. Other cases involved compelled falsehoods or compelled speech exist, but not in the same or even relatable context: in this case, it's clear that the recipient of the gag order made premeditated statements designed to allow them to make a compelled speech claim that sidesteps a gag order.

I suspect that the judicial system will not rule favorably on such a clear attempt to get around the gag order, and the end result may very well be a limitation on warrant "canaries" being published in the first place.

And, given that it's likely a case involving warrant canaries would be handled with the same level of secrecy as the actual proceedings leading up to it, this could have already happened without us even being aware.

mangeletti7• 11 years ago

What if there was a warrant canary service that killed the canary for you, unless you kept it alive on a regular basis (e.g., weekly, monthly) by providing a secret key and a message. The feds might be able to order you not to take the canary down, but they can't force you to post another update to a third-party canary to keep it alive. And, if they can, it might be time to revisit the role of our government.

jessaustin• 11 years ago

Why doesn't Canary Watch have a canary? They publish information that federal prosecutors might like to suppress. If a lesser-known service provider were targeted, and CW were forced to take down the relevant canary info first, how many people would realize it?

baby• 11 years ago

Maybe they used to have one until...

sdevlin4• 11 years ago

I wouldn't say this is bad or anything, but it is focusing on the wrong problem. Block ciphers like AES are the very strongest piece of the puzzle. This is kind of like putting three huge locks on your front door. It doesn't hurt, but the second and third locks have limited utility.

The best attack on this scheme (in a purely offline scenario) is probably just cracking weak passwords, just like it would have been with only one encryption pass.

EDIT: One more point. The FAQ says something about plans for a future streaming API. Please do not do this, at least for the decrypt operation. Streaming decryption APIs expose application developers to not-yet-authenticated plaintext.

EDIT EDIT: I think it's an API mistake to leave key generation in the hands of the user, especially by using a PBKDF. PBKDFs are a measure of last resort. If you can just generate key material randomly, you should do so.

mckiddy2• 11 years ago

Exactly, this will fail just as fast as a single cipher when your users inevitably use 'password123' for their password.

mangeletti7• 11 years ago

This is like saying, "A self driving car is a bad idea, because the user might enter the bottom of the ocean as their destination.".

CyberDildonics• 11 years ago

That's why you do password strengthening, which helps quite a bit.

sarciszewski3• 11 years ago

I wouldn't say this is bad or anything

I would.

The idea might not be bad, but the implementation is.

They use a pure software AES implementation that, due to its reliance on S-boxes, opens the door for cache-timing attacks.

Offending file: https://github.com/keybase/triplesec/blob/master/src/aes.ice...

Permalink: https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402...

Issue: https://github.com/keybase/triplesec/issues/47 (opened March 17, still collecting dust)

Reference: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

AES-NI or bust.

The FAQ says something about plans for a future streaming API. Please do not do this, at least for the decrypt operation. Streaming decryption APIs expose application developers to not-yet-authenticated plaintext.

I've written a streaming PoC to encrypt/decrypt file handles in PHP. During the decryption process, it first recalculates the HMAC over the entire file then verifies it with the one stored before decrypting. (Yes, in constant time too.) It's slower than just blindly decrypting, but more trustworthy.

Not quite the same as streaming network resources, but I figured that bit of nuance is worth mentioning.

The experiment lives here if you're interested in schooling me on some matter I overlooked, though I'm going to significantly rewrite it before I propose it to the project I was PoCing it for:

https://github.com/paragonie-scott/php-crypto-stream

(For starters, the actual pull request won't be using CBC.)

sdevlin4• 11 years ago

I was mainly commenting on the design. I actually haven't looked at the implementation.

Also, I would put AES side channels somewhat low on the list of practical vulnerabilities.

maxtaco• 11 years ago

Just commented on that issue. As you point out, most pure software implementations of AES still use S-Boxes, for better or worse. It's a risk to switch to a less standard and more complicated implementation to mitigate these attacks. Of course if you did TripleSec your data, the cache-timing attack is mitigated by the independent Salsa20 stream.

dimino2• 11 years ago

I've always assumed that a browser plugin would be the only way to establish even a semblance of integrity with regards to any security model attempting to encrypt/decrypt in a browser.

Is that not true?

acdha• 11 years ago

It is – any claims made about security are extremely hard to verify and even if you were to do so the code could change without notice, particularly if you're targeted Bryan advanced attacker.

Trust would require a managed crypto module which can provide strong assurances with a UI outside of the page's control.

Myrth• 11 years ago

Does it increase the cost of the proverbial wrench?

swordswinger12• 11 years ago

authenticates with HMAC to protect against adaptive chosen-ciphertext attacks

Okay...

TripleSec "macs" with a concatenation of two HMACs: HMAC-SHA-512, and HMAC-SHA3

Why?

axoltl• 11 years ago

The construction of the cipher doesn't solve the biggest problem with using these stream ciphers, re-use of the IV. Depending on your architecture it is very hard to guarantee that you'll never re-use an {IV, Key} pair.

Encrypting results in P xor S xor T xor A (where P is plaintext, S is Salsa, T is Twofish, A is AES (or rather, the key streams produced by each cipher)). If two different plaintexts were encrypted with the same IV and key pair then I can xor these two cipher texts together:

(P1 xor S xor T xor A) xor (P2 xor S xor T xor A) -> P1 xor P2

And I've now removed all of the crypto. AES-SIV aims to solve this problem, but is slower than something like AES-GCM because it needs to process the plaintext twice. Obviously, it is much faster than the scheme proposed here and removes the biggest implementation flaw in nonce-based stream ciphers.

Another pitfall here is that encryption == decryption (modulo the HMAC step) which means that if I have an encryption oracle that I can feed {IV, Key} that automatically becomes a decryption oracle. (The YubiHSM I believe was vulnerable to an attack like this, so they do happen in the real world)

TripleSec – Symmetric Encryption in the Browser Combining AES, Salsa20, Twofish

Related Stories