
TripleSec – Symmetric Encryption in the Browser Combining AES, Salsa20, Twofish - jessaustin
https://keybase.io/triplesec/
======
sdevlin
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.

~~~
sarciszewski
> 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...](https://github.com/keybase/triplesec/blob/master/src/aes.iced)

Permalink:
[https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402...](https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402f031486ae3671669daa05c/src/aes.iced)

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

Reference:
[http://cr.yp.to/antiforgery/cachetiming-20050414.pdf](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](https://github.com/paragonie-scott/php-crypto-stream)

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

~~~
sdevlin
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.

~~~
sarciszewski
> 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")

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

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

~~~
michaelsbradley
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](http://tonyarcieri.com/whats-wrong-with-webcrypto)

[2] [https://www.nccgroup.trust/us/about-us/newsroom-and-
events/b...](https://www.nccgroup.trust/us/about-us/newsroom-and-
events/blog/2011/august/javascript-cryptography-considered-harmful/)

~~~
explorigin
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...](http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/)

~~~
tedunangst
It's curious that you follow up a "really dated" article from 2011 with an
article from... 2010.

~~~
explorigin
The article that I posted, while older, presents a more realistic and
objective look at the JS crypto problem. I chose to criticize the matasano
article as "dated" because some of the positions it takes are no longer
accurate. The older article does not depend on dated information to make its
points.

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

See [https://canarywatch.org/faq.html](https://canarywatch.org/faq.html) for
more information.

~~~
akerl_
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.

~~~
mangeletti
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.

~~~
akerl_
My point is that given the clear connection the prosecution can make "they set
up this system specifically so that if we served them an NSL with a gag order
then they could circumvent the gag order", the odds of the judge saying "nah,
they got you" is low.

I expect either they receipient would be compelled to post updates, under the
grounds that by not posting updates they are speaking (the case would be that
the 3rd party system does not count as speech, and in fact not posting an
update would be speaking, because not updating is what conveys meaning to the
audience) or they'd find that speech can't be compelled _and_ you can't try to
end-run gag orders by using a "canary", so all the warrant canaries would
vanish more or less at once

~~~
mangeletti
I'm pretty sure
[https://www.law.cornell.edu/supremecourt/text/430/705](https://www.law.cornell.edu/supremecourt/text/430/705)
covers your first case, and
[https://www.law.cornell.edu/constitution/first_amendment](https://www.law.cornell.edu/constitution/first_amendment)
covers your second.

~~~
tedunangst
Let me guess. Only a 2L? Gonna cover constitutional law in your third year?
You may wish to read a bit more about the first amendment and its exceptions.

~~~
mangeletti
It's actually pretty simple and the text is pretty short. You should have a
read sometime. There are no exceptions, and it's pretty clear about that.

Now, that isn't to say that our judicial and executive branches of government
haven't ruined its enforceability, but that's a story about the resolve of our
citizens, not about the first amendment.

"Congress shall make no law respecting an establishment of religion, or
prohibiting the free exercise thereof; or abridging the freedom of speech, or
of the press; or the right of the people peaceably to assemble, and to
petition the Government for a redress of grievances."

------
dimino
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
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
Does it increase the cost of the proverbial wrench?

------
swordswinger12
>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?

