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.
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.
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?
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.
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 :-)
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.
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.
> What if there was a warrant canary service that killed the canary for you. 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.
If government can punish you for communicating prohibited information by action, it can also do so for using a pre-arranged absence of action to communicate the same information. If there is a legal prohibition on communicating the information, maneuvering around the mechanism to communicate the prohibited information isn't going to make it legal.
This. The judge is not a robot, and is unlikely to be fooled by "but I'm not releasing information, I'm removing information so it's not against the rules"
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
The latter outcome (that all canaries are banned) seems totally implausible from a first amendment point of view: it would prohibit anyone from ever saying "I've never received an NSL," period. The former (the compelled speech) seems like the more likely outcome to me.
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.
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."
There's just no technicality you can get away with here, because judges and juries are people too, and will know you're just trying to find a way to break the spirit of the law.
Providing a warrant canary through a service would expose it to more legal threats, not fewer. The more manual the process is, the better of a case you can make that it's a form of protected speech.
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?
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.
Except this also adds very little benefit. Sure, 3 ciphers might be better than one, but as the top comment said the cipher is already the strongest part of the entire process.
If the user enters the bottom of the ocean as their destination, it would be bad for a self-driving car to take them there. "The user is an idiot and so we killed him" is not going to be such a great defense in court...
In all seriousness, if a man puts a GLOCK 21 in his mouth and pulls the trigger, is it GLOCK that "killed him"?
If I take my car and intentionally drive into the ocean, I expect it to continue until the engine dies, and then I do shortly after. Why should machines start prohibiting me from doing stupid things, if I want to do them? I think Isaac Asimov wrote a parable about such a future.
There's no a priori need for password-derived key material in a library like this. To require it unilaterally is to introduce a security risk, since people have proven to be poor sources of entropy.
I don't really understand the self-driving car analogy. A better analogy would probably be three cars hitched together.
This is like saying "adding triple redundant GPS to a self driving car is a bad idea because the GPS is the component least likely to cause you to end up at the bottom of the ocean."
> 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:
> 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.
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.
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.
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.
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)
47 comments
[ 2.9 ms ] story [ 103 ms ] thread[1] https://security.stackexchange.com/questions/18197/why-shoul...
[1] http://tonyarcieri.com/whats-wrong-with-webcrypto
[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
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.
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?
http://blog.cryptographyengineering.com/2012/02/multiple-enc...
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.
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 :-)
See https://canarywatch.org/faq.html for more information.
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.
If government can punish you for communicating prohibited information by action, it can also do so for using a pre-arranged absence of action to communicate the same information. If there is a legal prohibition on communicating the information, maneuvering around the mechanism to communicate the prohibited information isn't going to make it legal.
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
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."
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.
If I take my car and intentionally drive into the ocean, I expect it to continue until the engine dies, and then I do shortly after. Why should machines start prohibiting me from doing stupid things, if I want to do them? I think Isaac Asimov wrote a parable about such a future.
I don't really understand the self-driving car analogy. A better analogy would probably be three cars hitched together.
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.)
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")
Is that not true?
Trust would require a managed crypto module which can provide strong assurances with a UI outside of the page's control.
Okay...
>TripleSec "macs" with a concatenation of two HMACs: HMAC-SHA-512, and HMAC-SHA3
Why?
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)