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

Re:TripleSec – Symmetric Encryption in the Browser Combining... by sarciszewski on Wednesday June 03, 2015 @06:41PM (#9656349)

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

[ Parent | on HN ]

Re:TripleSec – Symmetric Encryption in the Browser Combining... by sdevlin on Wednesday June 03, 2015 @06:51PM (#9656391)

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.

[ Parent | on HN ]

Re:TripleSec – Symmetric Encryption in the Browser Combining... by sarciszewski on Wednesday June 03, 2015 @06:53PM (#9656398)

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

Sure, but if they're concerned about weaknesses in AES enough to cascade it with other ciphers, ignoring the side-channel inherent to the AES design is pretty silly and indicates a lack of research or foresight.

Combine that with no response from their team for threee months after I opened the issue, and I think we can safely conclude that this library is not currently trustworthy.

(in b4 "TripleSec Considered Harmful")

[ Parent | on HN ]

Re:TripleSec – Symmetric Encryption in the Browser Combining... by maxtaco on Thursday June 04, 2015 @04:30PM (#9661843)

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.

[ Parent | on HN ]