Silk Road forums
Discussion => Security => Topic started by: Xennek on June 16, 2013, 05:59 pm
-
Why don't more people encrypt or at least privnote their addresses? Is there absolutely anything stopping LEAs/ "good" guys running a compromised exit node from reading your order list and adding all of the addresses to a watch list? Seems like an easy way to get nabbed to me.
-
Yes, there's a perfectly good reason they can't do that: traffic to and from Silk Road never goes through an exit node. It's all encrypted end-to-end in the Tor network and never leaves, thus is never sent unencrypted.
It's only stored unencrypted on the server and displayed unencrypted on the vendor's (and the buyer's) computers.
-
Why don't more people encrypt or at least privnote their addresses? Is there absolutely anything stopping LEAs/ "good" guys running a compromised exit node from reading your order list and adding all of the addresses to a watch list? Seems like an easy way to get nabbed to me.
Why would you think that privnote is safer than using the address field? Your address is automatically deleted from SR's servers too so why use a third party to do that for you? Privnote could keep a copy of all its messages for all we know.
-
Why don't more people encrypt or at least privnote their addresses? Is there absolutely anything stopping LEAs/ "good" guys running a compromised exit node from reading your order list and adding all of the addresses to a watch list? Seems like an easy way to get nabbed to me.
Why would you think that privnote is safer than using the address field? Your address is automatically deleted from SR's servers too so why use a third party to do that for you? Privnote could keep a copy of all its messages for all we know.
Privnote actually was -- at least at the time that I looked at it -- just as safe as PGP. Though I didn't go over it line by line or anything; still, the only real problem with it is that the code to encrypt stuff is downloaded on-the-fly from the server, and there's no guarantee that it hasn't changed since someone last looked at it.
By design, there will never be a guarantee that the code you download to encrypt the message wasn't changed the moment prior to you downloading it. That's why it isn't secure, but to my knowledge it's the only reason.
-
Oh I see, thanks for clarifying that. I would've thought privnote could somehow keep a copy of your message or not delete them. Does the source code of their site reveal that they can't?
I remember Pine was pretty opposed to using privnote though.
-
Um... Yeah, uh... I'm taking another look at this, and I'm going to retract my statement. I'm not so sure anymore, frankly: I'm quite positive that nothing is transmitted to the servers unencrypted. I am 100% _not_ positive however that the key to decrypt this shit is not in their possession.
-
Well I wasn't gonna start using privnote because of what you said anyways, I just found it interesting that it was pretty secure according to you. I prefer using PGP so I don't really care that much but for those that can't handle PGP it may be good to know how secure it really is.
-
Why don't more people encrypt or at least privnote their addresses?
Laziness and stupidity.
And yes, privnote is bad. Insecure. Not trust worthy.
-
Why don't more people encrypt or at least privnote their addresses? Is there absolutely anything stopping LEAs/ "good" guys running a compromised exit node from reading your order list and adding all of the addresses to a watch list? Seems like an easy way to get nabbed to me.
Why would you think that privnote is safer than using the address field? Your address is automatically deleted from SR's servers too so why use a third party to do that for you? Privnote could keep a copy of all its messages for all we know.
Privnote actually was -- at least at the time that I looked at it -- just as safe as PGP. Though I didn't go over it line by line or anything; still, the only real problem with it is that the code to encrypt stuff is downloaded on-the-fly from the server, and there's no guarantee that it hasn't changed since someone last looked at it.
By design, there will never be a guarantee that the code you download to encrypt the message wasn't changed the moment prior to you downloading it. That's why it isn't secure, but to my knowledge it's the only reason.
SelfSovereignty please stop making claims about technical things that you very clearly don't have a clue about, it is getting extremely annoying. Privnote is not anywhere near as secure as GPG. For one they could backdoor the code just like you said. For two you need to transfer the URL in plaintext or encrypt it with GPG, opening it up to massive MITM potential. The fact that a message is deleted automatically doesn't mean jack shit since somebody who does MITM will just intercept , read, make a new message. GPG is for getting around issues like that, privnote doesn't do jack shit to solve the underlying issues. Not to mention it is written in javascript, which is hardly the ideal language for doing crypto shit in. Not to mention you have not even looked at the code so how the hell are you to know if it is secure or not? Oh not to mention when you use privnote you are weak to your Tor exit node sending you a bugged version of the javascript client.
-
Why don't more people encrypt or at least privnote their addresses? Is there absolutely anything stopping LEAs/ "good" guys running a compromised exit node from reading your order list and adding all of the addresses to a watch list? Seems like an easy way to get nabbed to me.
Why would you think that privnote is safer than using the address field? Your address is automatically deleted from SR's servers too so why use a third party to do that for you? Privnote could keep a copy of all its messages for all we know.
Privnote actually was -- at least at the time that I looked at it -- just as safe as PGP. Though I didn't go over it line by line or anything; still, the only real problem with it is that the code to encrypt stuff is downloaded on-the-fly from the server, and there's no guarantee that it hasn't changed since someone last looked at it.
By design, there will never be a guarantee that the code you download to encrypt the message wasn't changed the moment prior to you downloading it. That's why it isn't secure, but to my knowledge it's the only reason.
SelfSovereignty please stop making claims about technical things that you very clearly don't have a clue about, it is getting extremely annoying. Privnote is not anywhere near as secure as GPG. For one they could backdoor the code just like you said. For two you need to transfer the URL in plaintext or encrypt it with GPG, opening it up to massive MITM potential. The fact that a message is deleted automatically doesn't mean jack shit since somebody who does MITM will just intercept , read, make a new message. GPG is for getting around issues like that, privnote doesn't do jack shit to solve the underlying issues. Not to mention it is written in javascript, which is hardly the ideal language for doing crypto shit in. Not to mention you have not even looked at the code so how the hell are you to know if it is secure or not? Oh not to mention when you use privnote you are weak to your Tor exit node sending you a bugged version of the javascript client.
... did I do something to offend you? Perhaps if you read 2 messages down you'd notice that I looked again and decided I was wrong. I'm not entirely sure what your tone is about, friend, but I made a statement; decided I needed to verify my statement because I couldn't quite remember what led me to the conclusion I came to; did so; decided I was wrong; and corrected it. Perhaps you'd like to tell me what I should have done, other than leaving a question completely unanswered while we all waited for you or astor to show up?
If I may indulge in a little bit of back-and-forth, if you will: anyone who says a language isn't suited to something because of its inherent properties as a language is a fool who pays more attention to standards and stereotypes than reality and truth. Any language that can accomplish something is a perfectly fine language to use for the task.
It's called Gibberish-AES, and in fact I have seen the code. Perhaps it's you who hasn't, friend.
In fact... you are so full of shit, I am not going to let this stand. Let me dissect your argument piece by piece.
Privnote is not anywhere near as secure as GPG. For one they could backdoor the code just like you said. For two you need to transfer the URL in plaintext or encrypt it with GPG, opening it up to massive MITM potential.
The question is in regard to plain text addresses, buddy. End-to-end encrypted within the Tor network. This doesn't apply.
The fact that a message is deleted automatically doesn't mean jack shit since somebody who does MITM will just intercept , read, make a new message.
Yes, this is true. It also has nothing to do with GPG since GPG doesn't make the same claim.
GPG is for getting around issues like that, privnote doesn't do jack shit to solve the underlying issues.
Plain text addresses you bloody loon, not the entire fucking universe.
Not to mention it is written in javascript, which is hardly the ideal language for doing crypto shit in.
You're a fucking idiot. Javascript to my knowledge is Turing complete. Someone will fucking write your personality in it someday, I guarantee you.
Not to mention you have not even looked at the code so how the hell are you to know if it is secure or not?
Again, Gibberish-AES. Go look it up.
Oh not to mention when you use privnote you are weak to your Tor exit node sending you a bugged version of the javascript client.
Here, however, you're correct. Which I stated initially -- no guarantee that the code will remain secure the moment before you encrypt. Why are you trying to throw my own points back at me?
In short: if you want to call someone an idiot, go look in a mirror.
-
... did I do something to offend you?
No nothing to offend me, it is just annoying to see you constantly going on about things and acting like you fully comprehend them when you clearly don't while making as many excuses for yourself as possible ('oh I am so tired', 'oh I didn't even read the full thing') in case you got something wrong (which you seem to do a lot). How about you read the papers you comment on, read the articles you comment on, read the source code of the program you comment on, and then come to a conclusion. You thought the attack on the implementation of that password safe program was an attack that cut AES key strength in half when it was an attack on the PBKDF, you dismissed Zerocoin as being impossible without even reading the whitepaper, you spoke poorly of the people who wrote the HSDIR attack paper because you confused rendezvous points with introduction points, and now you are saying that Privnote offers security equal to GPG when it obviously doesn't. So no I am not offended I am just annoyed that you keep spouting off nonsense when you don't even take the slightest time to research what you are talking about. Once or twice or three times or four times I would let it pass, and I even edited my post in the HSDIR attack thread after originally calling you out, but you consistently engage in spouting off about technical things that you are not understanding. And you do it in the most condescending way half of the time, like the security researchers writing these papers are idiots who don't know what they are talking about, simultaneously with making excuses for yourself and admitting that you have not even researched what you are commenting on or even finished reading the papers.
Perhaps if you read 2 messages down you'd notice that I looked again and decided I was wrong. I'm not entirely sure what your tone is about, friend, but I made a statement; decided I needed to verify my statement because I couldn't quite remember what led me to the conclusion I came to; did so; decided I was wrong; and corrected it. Perhaps you'd like to tell me what I should have done, other than leaving a question completely unanswered while we all waited for you or astor to show up?
You could have said nothing at all if you didn't know what you were talking about. I don't even care if people get things wrong, I doubt anybody here is a professional level security expert, but you don't say things that are wrong you make claims that are wrong. There is a big difference.
Privnote actually was -- at least at the time that I looked at it -- just as safe as PGP.
This is a false claim. If you had said
I think privnote is just as safe as PGP
I would have corrected you but not called you out. Hell even if you had just said this alone I wouldn't have cared, it is just a consistent theme I notice in your posts that has been consistently irritating me. It is okay to be wrong, it is annoying as hell when people consistently make definitive claims that are wrong, even more so when it is due to lack of research or even reading of the entire paper that they are commenting on.
-
If I may indulge in a little bit of back-and-forth, if you will: anyone who says a language isn't suited to something because of its inherent properties as a language is a fool who pays more attention to standards and stereotypes than reality and truth. Any language that can accomplish something is a perfectly fine language to use for the task.
Try again: http://www.matasano.com/articles/javascript-cryptography/
What do you mean, "Javascript cryptography"?
We mean attempts to implement security features in browsers using cryptographic algoritms implemented in whole or in part in Javascript.
You may now be asking yourself, "What about Node.js? What about non-browser Javascript?". Non-browser Javascript cryptography is perilous, but not doomed. For the rest of this document, we're referring to browser Javascript when we discuss Javascript cryptography.
Why does browser cryptography matter?
The web hosts most of the world's new crypto functionality. A significant portion of that crypto has been implemented in Javascript, and is thus doomed. This is an issue worth discussing.
What are some examples of "doomed" browser cryptography?
You have a web application. People log in to it with usernames and passwords. You'd rather they didn't send their passwords in the clear, where attackers can capture them. You could use SSL/TLS to solve this problem, but that's expensive and complicated. So instead, you create a challenge-response protocol, where the application sends Javascript to user browsers that gets them to send HMAC-SHA1(password, nonce) to prove they know a password without ever transmitting the password.
Or, you have a different application, where users edit private notes stored on a server. You'd like to offer your users the feature of knowing that their notes can't be read by the server. So you generate an AES key for each note, send it to the user's browser to store locally, forget the key, and let the user wrap and unwrap their data.
What's wrong with these examples?
They will both fail to secure users.
Really? Why?
For several reasons, including the following:
Secure delivery of Javascript to browsers is a chicken-egg problem.
Browser Javascript is hostile to cryptography.
The "view-source" transparency of Javascript is illusory.
Until those problems are fixed, Javascript isn't a serious crypto research environment, and suffers for it.
What's the "chicken-egg problem" with delivering Javascript cryptography?
If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.
That attack sounds complicated! Surely, you're better off with crypto than without it?
There are three misconceptions embedded in that common objection, all of them grave.
First, although the "hijack the crypto code to steal secrets" attack sounds complicated, it is in fact simple. Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted.
Second, the difficulty of an attack is irrelevant. What's relevant is how tractable the attack is. Cryptography deals in problems that intractable even stipulating an attacker with as many advanced computers as there are atoms composing the planet we live on. On that scale, the difficulty of defeating a cryptosystem delivered over an insecure channel is indistinguishable from "so trivial as to be automatic". Further perspective: we live and work in an uncertain world in which any piece of software we rely on could be found vulnerable to new flaws at any time. But all those flaws require new R&D effort to discover. Relative to the difficulty of those attacks, against which the industry deploys hundreds of millions of dollars every year, the difficulties of breaking Javascript crypto remain imperceptibly different than "trivial".
Finally, the security value of a crypto measure that fails can easily fall below zero. The most obvious way that can happen is for impressive-sounding crypto terminology to convey a false sense of security. But there are worse ways; for instance, flaws in login crypto can allow attackers to log in without ever knowing a user's password, or can disclose one user's documents to another user.
Why can't I use TLS/SSL to deliver the Javascript crypto code?
You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. Meanwhile, the Javascript crypto code is still imperiled by other browser problems.
What's hard about deploying Javascript over SSL/TLS?
You can't simply send a single Javascript file over SSL/TLS. You have to send all the page content over SSL/TLS. Otherwise, attackers will hijack the crypto code using the least-secure connection that builds the page.
How are browsers hostile to cryptography?
In a dispriting variety of ways, among them:
The prevalence of content-controlled code.
The malleability of the Javascript runtime.
The lack of systems programming primitives needed to implement crypto.
The crushing weight of the installed base of users.
Each of these issues creates security gaps that are fatal to secure crypto. Attackers will exploit them to defeat systems that should otherwise be secure. There may be no way to address them without fixing browsers.
What do you mean by "content-controlled code"? Why is it a problem?
We mean that pages are built from multiple requests, some of them conveying Javascript directly, and some of them influencing Javascript using DOM tag attributes (such as "onmouseover").
Ok, then I'll just serve a cryptographic digest of my code from the same server so the code can verify itself.
This won't work.
Content-controlled code means you can't reason about the security of a piece of Javascript without considering every other piece of content that built the page that hosted it. A crypto routine that is completely sound by itself can be utterly insecure hosted on a page with a single, invisible DOM attribute that backdoors routines that the crypto depends on.
This isn't an abstract problem. It's an instance of "Javascript injection", better known to web developers as "cross-site scripting". Virtually every popular web application ever deployed has fallen victim to this problem, and few researchers would take the other side of a bet that most will again in the future.
Worse still, browsers cache both content and Javascript aggressively; caching is vital to web performance. Javascript crypto can't control the caching behavior of the whole browser with specificity, and for most applications it's infeasible to entirely disable caching. This means that unless you can create a "clean-room" environment for your crypto code to run in, pulling in no resource tainted by any other site resource (from layout to UX) , you can't even know what version of the content you're looking at.
What's a "malleable runtime"? Why are they bad?
We mean you can change the way the environment works at runtime. And it's not bad; it's a fantastic property of a programming environment, particularly one used "in the small" like Javascript often is. But it's a real problem for crypto.
The problem with running crypto code in Javascript is that practically any function that the crypto depends on could be overridden silently by any piece of content used to build the hosting page. Crypto security could be undone early in the process (by generating bogus random numbers, or by tampering with constants and parameters used by algorithms), or later (by spiriting key material back to an attacker), or --- in the most likely scenario --- by bypassing the crypto entirely.
There is no reliable way for any piece of Javascript code to verify its execution environment. Javascript crypto code can't ask, "am I really dealing with a random number generator, or with some facsimile of one provided by an attacker?" And it certainly can't assert "nobody is allowed to do anything with this crypto secret except in ways that I, the author, approve of". These are two properties that often are provided in other environments that use crypto, and they're impossible in Javascript.
Well then, couldn't I write a simple browser extension that would allow Javascript to verify itself?
You could. It's harder than it sounds, because you'd have to verify the entire runtime, including anything the DOM could contribute to it, but it is theoretically possible. But why would you ever do that? If you can write a runtime verifier extension, you can also do your crypto in the extension, and it'll be far safer and better.
"But", you're about to say, "I want my crypto to be flexible! I only want the bare minimum functionality in the extension!" This is a bad thing to want, because ninety-nine and five-more-nines percent of the crypto needed by web applications would be entirely served by a simple, well-specified cryptosystem: PGP.
The PGP cryptosystem is approaching two decades of continuous study. Just as all programs evolve towards a point where they can read email, and all languages contain a poorly-specified and buggy implementation of Lisp, most crypto code is at heart an inferior version of PGP. PGP sounds complicated, but there is no reason a browser-engine implementation would need to be (for instance, the web doesn't need all the keyring management, the "web of trust", or the key servers). At the same time, much of what makes PGP seem unwieldy is actually defending against specific, dangerous attacks.
You want my browser to have my PGP key?
Definitely not. It'd be nice if your browser could generate, store, and use its own PGP keys though.
What systems programming functionality does Javascript lack?
Here's a starting point: a secure random number generator.
How big a deal is the random number generator?
Virtually all cryptography depends on secure random number generators (crypto people call them CSPRNGs). In most schemes, the crypto keys themselves come from a CSPRNG. If your PRNG isn't CS, your scheme is no longer cryptographically secure; it is only as secure as the random number generator.
But how easy is it to attack an insecure random generator, really?
It's actually hard to say, because in real cryptosystems, bad RNGs are a "hair on fire" problem solved by providing a real RNG. Some RNG schemes are pencil-and-paper solveable; others are "crackable", like an old DES crypt(3) password. It depends on the degree of badness you're willing to accept. But: no SSL system would accept any degree of RNG badness.
But I can get random numbers over the Internet and use them for my crypto!
How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL.
I'll use RANDOM.ORG. They support SSL.
“Javascript Cryptography. It's so bad, you’ll consider making async HTTPS requests to RANDOM.ORG simply to fetch random numbers."
-
continued ....
Imagine a system that involved your browser encrypting something, but filing away a copy of the plaintext and the key material with an unrelated third party on the Internet just for safekeeping. That's what this solution amounts to. You can't outsource random number generation in a cryptosystem; doing so outsources the security of the system.
What else is the Javascript runtime lacking for crypto implementors?
Two big ones are secure erase (Javascript is usually garbage collected, so secrets are lurking in memory potentially long after they're needed) and functions with known timing characteristics. Real crypto libraries are carefully studied and vetted to eliminate data-dependant code paths --- ensuring that one similarly-sized bucket of bits takes as long to process as any other --- because without that vetting, attackers can extract crypto keys from timing.
But other languages have the same problem!
That's true. But what's your point? We're not saying Javascript is a bad language. We're saying it doesn't work for crypto inside a browser.
But people rely on crypto in languages like Ruby and Java today. Are they doomed, too?
Some of them are; crypto is perilous.
But many of them aren't, because they can deploy countermeasures that Javascript can't. For instance, a web app developer can hook up a real CSPRNG from the operating system with an extension library, or call out to constant-time compare functions.
If Python was the standard browser content programming language, browser Python crypto would also be doomed.
What else is Javascript missing?
A secure keystore.
What's that?
A way to generate and store private keys that doesn't depend on an external trust anchor.
External what now?
It means, there's no way to store a key securely in Javascript that couldn't be expressed with the same fundamental degree of security by storing the key on someone else's server.
Wait, can't I generate a key and use it to secure things in HTML5 local storage? What's wrong with that?
That scheme is, at best, only as secure as the server that fed you the code you used to secure the key. You might as well just store the key on that server and ask for it later. For that matter, store your documents there, and keep the moving parts out of the browser.
These don't seem like earth-shattering problems. We're so close to having what we need in browsers, why not get to work on it?
Check back in 10 years when the majority of people aren't running browsers from 2008.
That's the same thing people say about web standards.
Compare downsides: using Arial as your typeface when you really wanted FF Meta, or coughing up a private key for a crypto operation.
We're not being entirely glib. Web standards advocates care about graceful degradation, the idea that a page should at least be legible even if the browser doesn't understand some advanced tag or CSS declaration.
"Graceful degradation" in cryptography would imply that the server could reliably identify which clients it could safely communicate with, and fall back to some acceptable substitute in cases where it couldn't. The former problem is unsolved even in the academic literature. The latter recalls the chicken-egg problem of web crypto: if you have an acceptable lowest-common-denominator solution, use that instead.
This is what you meant when you referred to the "crushing burden of the installed base"?
Yes.
And when you said "view-source transparency was illusory"?
We meant that you can't just look at a Javascript file and know that it's secure, even in the vanishingly unlikely event that you were a skilled cryptographer, because of all the reasons we just cited.
Nobody verifies the software they download before they run it. How could this be worse?
Nobody installs hundreds of applications every day. Nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps.
This is a big deal: it means attackers have many hundreds of opportunities to break web app crypto, where they might only have one or two opportunities to break a native application.
But people give their credit cards to hundreds of random people insecurely.
An attacker can exploit a flaw in a web app across tens or hundreds of thousands of users at one stroke. They can't get a hundred thousand credit card numbers on the street.
You're just not going to give an inch on this, are you?
Nobody would accept any of the problems we're dredging up here in a real cryptosystem. If SSL/TLS or PGP had just a few of these problems, it would be front-page news in the trade press.
You said Javascript crypto isn't a serious research area.
It isn't.
How much research do we really need? We'll just use AES and SHA256. Nobody's talking about inventing new cryptosystems.
AES is to "secure cryptosystems" what uranium oxide pellets are to "a working nuclear reactor". Ever read the story of the radioactive boy scout? He bought an old clock with painted with radium and found a vial of radium paint inside. Using that and a strip of beryllium swiped from his high school chemistry lab, he built a radium gun that irradiated pitchblende. He was on his way to building a "working breeder reactor" before moon-suited EPA officials shut him down and turned his neighborhood into a Superfund site.
The risks in building cryptography directly out of AES and SHA routines are comparable. It is capital-H Hard to construct safe cryptosystems out of raw algorithms, which is why you generally want to use high-level constructs like PGP instead of low-level ones.
What about things like SJCL, the Stanford crypto library?
SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.
SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.
Aren't you creating a self-fulfilling prophecy about Javascript crypto research?
People don't take Javascript crypto seriously because they can't get past things like "there's no secure way to key a cryptosystem" and "there's no reliably safe way to deliver the crypto code itself" and "there's practically no value to doing crypto in Javascript once you add SSL to the mix, which you have to do to deliver the code".
These may be real problems, but we're talking about making crypto available to everyone on the Internet. The rewards outweigh the risks!
DETROIT --- A man who became the subject of a book called "The Radioactive Boy Scout" after trying to build a nuclear reactor in a shed as a teenager has been charged with stealing 16 smoke detectors. Police say it was a possible effort to experiment with radioactive materials.
The world works the way it works, not the way we want it to work. It's one thing to point at the flaws that make it hard to do cryptography in Javascript and propose ways to solve them; it's quite a different thing to simply wish them away, which is exactly what you do when you deploy cryptography to end-users using their browser's Javascript runtime.
-
Privnote is not anywhere near as secure as GPG. For one they could backdoor the code just like you said. For two you need to transfer the URL in plaintext or encrypt it with GPG, opening it up to massive MITM potential.
The question is in regard to plain text addresses, buddy. End-to-end encrypted within the Tor network. This doesn't apply.
Lol are you kidding me? Why the fuck even use privnote if the end to end encryption of Tor is enough to protect you? Do you understand the difference between link encryption and message encryption? Just because Tor hidden services use end to end encrypted links doesn't mean that the message is encrypted when it is stored on the server. That is the reason why we use GPG, to add message encryption as well. So that when the message is sitting on the server it cannot be intercepted and decrypted. When a privnote link is sitting on the server it can be intercepted and the message can be obtained. So it is completely worthless for our purposes. Privnote symmetrically encrypts the message and then you hand out the symmetric key without using an asymmetric algorithm for session key transfer. I might as well AES encrypt a message to the vendor and send them the password to decrypt it along with the ciphertext. That is what privnote is doing. It isn't even the same thing as GPG, which is a hybrid cryptosystem. Privnote is a retarded implementation of a symmetric encryption algorithm that they are tricking idiots into using instead of an asymmetric-symmetric cryptosystem like GPG.
It would be nice if you had a basic understanding of the fundamentals of cryptography prior to trying to argue with me.
The fact that a message is deleted automatically doesn't mean jack shit since somebody who does MITM will just intercept , read, make a new message.
Yes, this is true. It also has nothing to do with GPG since GPG doesn't make the same claim.
It has everything to do with GPG because if I send a vendor a message encrypted with GPG the attacker can not read my message but if I send the vendor a privnote message the attacker can read my message and then replace it such that the vendor never knows the message was read. That means that Privnote has 0 security, it accomplishes jack fucking shit. I send the vendor a link to a symmetrically encrypted message and in plaintext I send them the symmetric key, so obviously the encryption isn't helping a god damn thing. That means the security of the system entirely depends on privnote deleting messages after they are read once, so the vendor can tell if their message was intercepted, but oh the MITM attacker can just recreate the same exact message and send the vendor the new link. So Privnote accomplishes absolutely nothing at all, GPG accomplishes something.
GPG is for getting around issues like that, privnote doesn't do jack shit to solve the underlying issues.
Plain text addresses you bloody loon, not the entire fucking universe.
I don't even understand what the hell you are talking about here??
Not to mention it is written in javascript, which is hardly the ideal language for doing crypto shit in.
You're a fucking idiot. Javascript to my knowledge is Turing complete. Someone will fucking write your personality in it someday, I guarantee you.
Ho hum, can javascript even do constant time operations. Get a clue before making claims plz.
Not to mention you have not even looked at the code so how the hell are you to know if it is secure or not?
Again, Gibberish-AES. Go look it up.
You are the one who said you never looked at the code in the first place. Anyway AES implemented in javascript is not likely to be very secure.
Oh not to mention when you use privnote you are weak to your Tor exit node sending you a bugged version of the javascript client.
Here, however, you're correct. Which I stated initially -- no guarantee that the code will remain secure the moment before you encrypt. Why are you trying to throw my own points back at me?
In short: if you want to call someone an idiot, go look in a mirror.
Your initial statement was that GPG and Privnote are of equal security, and I never called anyone an idiot but you did just clarify for me that you are one.
-
http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/
The talk I gave last year on common crypto flaws still seems to generate comments. The majority of the discussion is by defenders of Javascript crypto. I made JS crypto a very minor part of the talk because I thought it would be obvious why it is a bad idea. Apparently, I was wrong to underestimate the grip it seems to have on web developers.
Rather than repeat the same rebuttals over and over, this is my final post on this subject. It ends with a challenge — if you have an application where Javascript crypto is more secure than traditional implementation approaches, post it in the comments. I’ll write a post citing you and explaining how you changed my mind. But since I expect this to be my last post on the matter, read this article carefully before posting.
To illustrate the problems with JS crypto, let’s use a simplified example application: a secure note-taker. The user writes notes to themselves that they can access from multiple computers. The notes will be encrypted by a random key, which is itself encrypted with a key derived from a passphrase. There are three implementation approaches we will consider: traditional client-side app, server-side app, and Javascript crypto. We will ignore attacks that are common to all three implementations (e.g., weak passphrase, client-side keylogger) and focus on their differences.
The traditional client-side approach offers the most security. For example, you could wrap PGP in a GUI with a notes field and store the encrypted files and key on the server. A client who is using the app is secure against future compromise of the server. However, they are still at risk of buggy or trojaned code each time they download the code. If they are concerned about this kind of attack, they can store a local copy and have a cryptographer audit it before using it.
The main advantage to this approach is that PGP has been around almost 20 years. It is well-tested and the GUI author is unlikely to make a mistake in interfacing with it (especially if using GPGME). The code is open-source and available for review.
If you don’t want to install client-side code, a less-secure approach is a server-side app accessed via a web browser. To take advantage of existing crypto code, we’ll use PGP again but the passphrase will be sent to it via HTTP and SSL. The server-side code en/decrypts the notes using GPGME and pipes the results to the user.
Compared to client-side code, there are a number of obvious weaknesses. The passphrase can be grabbed from the memory of the webserver process each time it is entered. The PGP code can be trojaned, possibly in a subtle way. The server’s /dev/urandom can be biased, weakening any keys generated there.
The most important difference from a client-side attack is that it takes effect immediately. An attacker who trojans a client app has to wait until users download and start using it. They can copy the ciphertext from the server, but it isn’t accessible until someone runs their trojan, exposing their passphrase or key. However, a server-side trojan takes effect immediately and all users who access their notes during this time period are compromised.
Another difference is that the password is exposed to a longer chain of software. With a client-side app, the passphrase is entered into the GUI app and passed over local IPC to PGP. It can be wiped from RAM after use, protected from being swapped to disk via mlock(), and generally remains under the user’s control. With the server-side app, it is entered into a web browser (which can cache it), sent over HTTPS (which involves trusting hundreds of CAs and a complex software stack), hits a webserver, and is finally passed over local IPC to PGP. A compromise of any component of that chain exposes the password.
The last difference is that the user cannot audit the server to see if an attack has occurred. With client-side code, the user can take charge of change management, refusing to update to new code until it can be audited. With a transport-level attack (e.g., sslstrip), there is nothing to audit after the fact.
The final implementation approach is Javascript crypto. The trust model is similar to server-side crypto except the code executes in the user’s browser instead of on the server. For our note-taker app, the browser would receive a JS crypto library over HTTPS. The first time it is used, it generates the user’s encryption key and encrypts it with the passphrase (say, derived via PBKDF2). This encrypted key is persisted on the server. The notes files are en/decrypted by the JS code before being sent to the server.
Javascript crypto has all the same disadvantages as server-side crypto, plus more. A slightly modified version of all the server-side attacks still works. Instead of trojaning the server app, an attacker can trojan the JS that is sent to the user. Any changes to the code immediately take effect for all active users. There’s the same long chain of software having access to critical data (JS code and the password processed by it).
So what additional problems make JS crypto worse than the server-side approach?
Numerous libraries not maintained by cryptographers — With a little searching, I found: clipperz, etherhack, Titaniumcore, Dojo, crypto-js, jsSHA, jscryptolib, pidCrypt, van Everdingen’s library, and Movable Type’s AES. All not written or maintained by cryptographers. One exception is Stanford SJCL, although that was written by grad students 6 months ago so it’s too soon to tell how actively tested/maintained it will be.
New code has not been properly reviewed and no clear “best practices” for implementers — oldest library I can find is 2 years old. Major platform-level questions still need to be resolved by even the better ones.
Low-level primitives only — grab bag of AES, Serpent, RC4, and Caesar ciphers (yes, in same library). No high-level operations like GPGME. Now everyone can (and has to) be a crypto protocol designer.
Browser is low-assurance environment — same-origin policy is not a replacement for ACLs, privilege separation, memory protection, mlock(), etc. JS DOM allows arbitrary eval on each element and language allows rebinding most operations (too much flexibility for crypto).
Poor crypto support — JS has no secure PRNG such as /dev/urandom, side channel resistance is much more difficult if not impossible
Too many platforms — IE, Firefox, Netscape, Opera, WebKit, Konqueror, and all versions of each. Crypto code tends to fail catastrophically in the face of platform bugs.
Auditability — each user is served a potentially differing copy of the code. Old code may be running due to browser cache issues. Impossible for server maintainers to audit clients.
JS crypto is not even better for client-side auditability. Since JS is quite lenient in allowing page elements to rebind DOM nodes, even “View Source” does not reveal the actual code running in the browser. You’re only as secure as the worst script run from a given page or any other pages it allows via document.domain.
I have only heard of one application of JS crypto that made sense, but it wasn’t from a security perspective. A web firm processes credit card numbers. For cost reasons, they wanted to avoid PCI audits of their webservers, but PCI required any server that handled plaintext credit card numbers to be audited. So, their webservers send a JS crypto app to the browser client to encrypt the credit card number with an RSA public key. The corresponding private key is accessible only to the backend database. So based on the wording of PCI, only the database server requires an audit.
Of course, this is a ludicrous argument from a security perspective. The webserver is a critical part of the chain of trust in protecting the credit card numbers. There are many subtle ways to trojan RSA encryption code to disclose the plaintext. To detect trojans, the web firm has a client machine that repeatedly downloads and checksums the JS code from each webserver. But an attacker can serve the original JS to that machine while sending trojaned code to other users.
While I agree this is a clever way to avoid PCI audits, it does not increase actual security in any way. It is still subject to the above drawbacks of JS crypto.
If you’ve read this article and still think JS crypto has security advantages over server-side crypto for some particular application, describe it in a comment below. But the burden of proof is on you to explain why the above list of drawbacks is addressed or not relevant to your system. Until then, I am certain JS crypto does not make security sense.
Just because something can be done doesn’t mean it should be.
Epilogue
Auditability of client-side Javascript
I had overstated the auditability of JS in the browser environment by saying the code was accessible via “View Source”. It turns out the browser environment is even more malleable than I first thought. There is no user-accessible menu that tells what code is actually executing on a given page since DOM events can cause rebinding of page elements, including your crypto code. Thanks to Thomas Ptacek for pointing this out. I updated the corresponding paragraph above.
JS libraries such as jQuery, Prototype, and YUI all have APIs for loading additional page elements, which can be HTML or JS. These elements can rebind DOM nodes, meaning each AJAX query can result in the code of a page changing, not just the data displayed. The APIs don’t make a special effort to filter out page elements, and instead trust that you know what you’re doing.
The same origin policy is the only protection against this modification. However, this policy is applied at the page level, not script level. So if any script on a given page sets document.domain to a “safe” value like “example.net”, this would still allow JS code served from “ads.example.net” to override your crypto code on “www.example.net”. Your page is only as secure as the worst script loaded from it.
Brendan Eich made an informative comment on how document.domain is not the worst issue, separation of privileges for cross-site scripts is:
Scripts can be sourced cross-site, so you could get jacked without document.domain entering the picture just by <script src=”evil.ads.com”>. This threat is real but it is independent of document.domain and it doesn’t make document.domain more hazardous. It does not matter where the scripts come from. They need not come from ads.example.net — if http://www.example.net HTML loads them, they’re #include’d into http://www.example.net’s origin (whether it has been modified by document.domain or not).
In other words, if you have communicating pages that set document.domain to join a common superdomain, they have to be as careful with cross-site scripts as a single page loaded from that superdomain would. This suggests that document.domain is not the problem — cross-site scripts having full rights is the problem. See my W2SP 2009 slides.
“Proof of work” systems
Daniel Franke suggested one potentially-useful application for JS crypto: “proof of work” systems. These systems require the client to compute some difficult function to increase the effort required to send spam, cause denial of service, or bruteforce passwords. While I agree this application would not be subject to the security flaws listed in this article, it would have other problems.
Javascript is many times slower than native code and much worse for crypto functions than general computation. This means the advantage an attacker has in creating a native C plus GPU execution environment will likely far outstrip any slowness legitimate users will accept. If the performance ratio between attacker and legitimate users is too great, Javascript can’t be used for this purpose.
He recognized this problem and also suggested two ways to address it: increase the difficulty of the work function only when an attack is going on or only for guesses with weak passphrases. The problem with the first is that an attacker can scale up their guessing rate until the server slows down and then stay just below that threshold. Additionally, she can parallelize guesses for multiple users, depending on what the server uses for rate-limiting. One problem with the second is that it adds a round-trip where the server has to see the length of the attacker’s guess before selecting a difficulty for the proof-of-work function. In general, it’s better to select a one-size-fits-all parameter than to try to dynamically scale.
Browser plugin can checksum JS crypto code
This idea helps my argument, not hurts it. If you can deploy a custom plugin to clients, why not run the crypto there? If it can access the host environment, it has a real PRNG, crypto library (Mozilla NSS or Microsoft CryptoAPI), etc. Because of Javascript’s dynamism, no one knows a secure way to verify signatures on all page elements and DOM updates, so a checksumming plugin would not live up to its promise.
-
Call me psychic, but I think kmfkewm is a tad frustrated at SS...
@OP - Laziness to not learn PGP and sheer ignorance of their own security. I see it as natural selection and so increasing the median IQ of our users to an acceptable equilibrium of intelligencia and fools.
-
Alright I lied, I'm not done. This anger and these insults are unbecoming, and I would like to apologize for them. Here is my calm response:
I did not intend to ever, at any time, state that Privnote is universally as secure as PGP encryption. If that is what you believe I meant, then you were absolutely correct in making sure to point out I was wrong. If what I said sounded like I really meant that, then some of the fault is indeed with me. That statement is a false one.
Again, I didn't mean to say that. Now is there anything you would like to continue arguing about? Because I believe that is the root of this disagreement, and whether you like me or I like you aside, I believe that the discussion is done. I am, however, here and willing to participate in it further if you desire. So: are we done?
-
... you are a fucking... retard. I mean you really are like some fucking idiot savant pedophile, aren't you?
I pretty openly admit that I am mildly autistic, with traits of savantism, in addition to being non-exclusively ephebephilic, which is colloquially considered to be pedophilia in a minority of the world. If you meant that as an insult to me it didn't really come across as such.
1. I do not know more about cryptography than you do. You know more about it than me. I freely admit that.
I am not trying to compete with you. Mostly I am trying to get you to start reading things through before you comment on them. This was the straw that broke the camels back for me. It was also the most insidious of your misconceptions, if you think Zerocoin is impossible it doesn't really matter, but when people hear a respected member of the community say that Privnote is just as safe as GPG it leads to very real insecure practices.
2. In the real world, my friend, you have tasks that need to be accomplished. To say a tool is unsuited to a task when it can accomplish it is blind idiocy. To say it is NOT THE BEST tool for the job is perfectly rational, but it is what goes into that conclusion that matters. WHO GIVES A FUCK IF JAVASCRIPT IS SLOW AND INEFFICIENT AND FUCKING BLOWS TO WRITE?! Does it get the job done -- yes? Then who gives a fuck -- other than you, nobody sane should.
You are not comprehending the problems with javascript. Javascript being slow doesn't matter, javascript not being able to carry out operations in fixed units of time makes it unsuitable for cryptography. Javascript can not accomplish a secure implementation of a cryptographic algorithm. You can implement AES to specification in javascript, but the fact that it is implemented in javascript will make it an insecure implementation even if it perfectly follows the specification. The articles I linked to also point out a variety of other issues, ranging from lack of secure CSPRNG, lack of ability to protect from MITM attacks, etc. Javascript crypto is death by a million side channel attacks. I don't even claim to be a professional cryptographer, because I am not one. I know enough to implement some basic block ciphers, pseudorandom number generators, etc, but I sure as hell cannot design something like AES or even implement something like AES. But I listen to professional cryptographers, and the thing I always hear from them is that javascript and cryptography do not mix. Interpreted languages and cryptography do not mix. You can end up with something that looks like it works, and something that follows the specification, but the inherent weaknesses of the languages run time environment will side channel the shit out of the cryptosystem. Browser based javascript is even worse, in addition to having all of the problems of javascript it also has the weaknesses to MITM etc that come from it being browser based.
So to answer your question: professional cryptographers give a fuck. The people who don't seem to give a fuck are people who know how to program in javascript and write web applications, but who have absolutely zero education in programming cryptographically secure applications. It seems everybody who knows how to program thinks that they are inherently a cryptographer because of it.
This is fucking pointless, I'm not going to itemize pages and pages and pages that have NOTHING TO DO with what I said. No one in their right mind would claim Javascript is BETTER than any other language for crypto. But how many languages does EVERY FUCKING BROWSER in the world implement? Javascript is about the only fucking one. Therefore it was the right tool for the job of Privnote. I don't understand why you don't get that or why the fuck you would try to argue about it? I mean you do understand how browsers and interpreters work... right?
You are the one who clearly doesn't understand how interpreters work, and how that is contradictory to the goals of cryptographically secure programming. Privnote is an extremely poorly designed cryptosystem that was written in a language that shouldn't be used for implementing cryptographic algorithms in, in the worst way they could have used the language to implement their broken system. I do understand that javascript was the 'right tool' for the job of Privnote, but what you don't seem to understand is that the right tool can sometimes make the wrong product. A hammer is the right tool to make a wooden box with, it doesn't mean you should build a wooden box with a hammer and then try to use it as a submarine. It also doesn't mean that you can build a submarine with a hammer.
You are a truly pathetic little man, my friend. I sincerely hope you enjoy your life. I really do. And with that I am done.
k thanks
-
I am pasting the modification to my post which you clearly did not read. Please respond to it, and only it, because again, you are arguing against points which are not ones I meant to make.
Alright I lied, I'm not done. This anger and these insults are unbecoming, and I would like to apologize for them. Here is my calm response:
I did not intend to ever, at any time, state that Privnote is universally as secure as PGP encryption. If that is what you believe I meant, then you were absolutely correct in making sure to point out I was wrong. If what I said sounded like I really meant that, then some of the fault is indeed with me. That statement is a false one.
Again, I didn't mean to say that. Now is there anything you would like to continue arguing about? Because I believe that is the root of this disagreement, and whether you like me or I like you aside, I believe that the discussion is done. I am, however, here and willing to participate in it further if you desire. So: are we done?
-
Alright I lied, I'm not done. This anger and these insults are unbecoming, and I would like to apologize for them. Here is my calm response:
I also would like to point out that I am not angry at you, and that insulting you was not my primary goal. I merely wanted to express some irritation I had with some of your posts, indeed with a very tiny minority of your posts. I don't have any problem with you at all and don't want to fight with you (although I do love to debate things!), and I probably should have expressed myself in a less hostile way. So I apologize for any hostility perceived from me.
I did not intend to ever, at any time, state that Privnote is universally as secure as PGP encryption. If that is what you believe I meant, then you were absolutely correct in making sure to point out I was wrong. If what I said sounded like I really meant that, then some of the fault is indeed with me. That statement is a false one.
Yes that is definitely how I took what you said.
Again, I didn't mean to say that. Now is there anything you would like to continue arguing about? Because I believe that is the root of this disagreement, and whether you like me or I like you aside, I believe that the discussion is done. I am, however, here and willing to participate in it further if you desire. So: are we done?
I didn't mean to insult you personally, out of all of your 2,077 posts there have only been about 5 that bothered me. I just wanted to let you know how irritating I found you to be in those 5 posts, is all. If you want to continue arguing for or against javascript based cryptography, or related things, then I am game for that. However, otherwise I don't really care I think we both made all of our points related to Privnote and each other lol.