Silk Road forums
Discussion => Security => Topic started by: Scot Walker on January 20, 2012, 02:53 am
-
There's a seller that I want to buy from, but he only uses Privnote, no PGP. Is it safe to send an address using it?
Thanks!
-
I had the same thought as you when first asked to use Privnote, so did some research. In brief my conclusion was that either the site is totally compromised and run by some federal organisation, or its pretty safe, depends whether I have my paranoia mode on full.
The technology it uses is a reasonably secure concept - the url that is generated is in two parts, one is the actual address of the note, and the other is an encryption key. They say they dont store the urls themselves, so their servers only contain encrypted data with no keys to decode it.
They also say that they dont record any IP addresses, so your notes should not be traceable back to you, which also means they shouldnt be able to prove that it was actually you who sent your address to some SR vendor rather than your malicious stalker looking to incriminate you.
There is https://certified.privnote.com/ which is the "Europrise" certified version of Privnote, means it has the European Privacy Seal issued by an EU organisation. Again this won't reassure you if you have max paranoia since then you have to assume the feds have control of everything.
Personally, I wouldnt use it for high risk/value business (if I did any) but I have used it for small SR purchases.
-
Yeah, for what you're trying to do. I'm sure if you put some top secret classified info there it could be found out.
-
Privnote.com is currently hosted at Rackspace Hosting.
The IP 174.143.172.154 links to a server in San Antonio, United States.
The company behind this all is Slicehost
The privnote.com server is powered by Apache/2.2.14 (Ubuntu) webserver software
The developers of Privnote have built the app by using Django and Python
- perhaps stick with gpg / pgp as already suggested.
-
So here's what happens when you create a note in Privnote:
You write the note and click the POST button
The server generates a random note id, let's call it the NoteID. This is the 16 chars ID you see in the note link
The server hashes the note ID and gets a HashedNoteID = Hash(NoteID). We're currently using SHA-1 as the hashing algorithm, but the particular algorithm is not very important here
The server encrypts the note contents (and also the email and reference, if there is any) using the NoteID, and stores the encrypted version in the database using the HashedNoteID as the database primary key
If someone with access to the database would like to read the note she would be unable because she doesn't have the key to decrypt it (NoteID), only the database primary key (HashedNoteID). The HashedNoteID cannot be used to "go back" to the NoteID because hashes are "one-way". So the only person who can actually decrypt (and thus see) the note is the one who has the original NoteID or, in other words, the one who has the link to the note.
For completeness, this is what happens when you view a note in Privnote:
The server extracts the NoteID from the URL
The server hashes the NoteID and gets the HashedNoteID. This is the same HashedNoteID used when generating the note, since the NoteID used to make the hash is the same in both cases
The server retrieves the note from the database using HashedNoteID as the database primary key and decrypts its contents using NoteID as the encryption key
The server shows the page with the decrypted note
The server permanently deletes the note from the database, keeping only a record of the HashedNoteID, the time when it was read, and the IP address where it was read from, to show it when someone tries to see the note again
-
Actually we don't know how privnote works, only how they claim that it works. It might just store everything unencrypted, or it might store the encryption keys for employees and law enforcement to use.
We do know how PGP works. You can download the source code, inspect it, compile it, and even compare the compiled binaries to the ones that are being distributed to see if they differ.
Privnote should be considered insecure for 2 reasons. The first, we can't prove that it is secure, so it is safer to assume that it is insecure. The second, it is insecure. I explained why in my last post. If you send a privnote link over the SR messaging system, SR can read the contents. So why not send the message over SR unencrypted in the first place?
This man knows what he is talking about (on this particular issue anyway...not sure about others)
Can anyone explain to me what the purpose of sending someone a privnote link over SR messaging is supposed to accomplish security wise? How is it more secure than a normal unencrypted SR message?
It is not more secure, and is less secure
Before someone says that the message can only be read once, proving that SR read it before the intended recipient, stop and think about it for a minute. SR could just read the message, create a new privnote with the same data, and then pass that along. The entire thing could be scripted. SR messaging sees a privnote link, reads the data, creates a new privnote, modifies the message and then sends it to the user it was intended for.
Classical man in the middle attack. To be fair SR could do the same thing during GPG key exchange and this is why measures against this must be taken.
On the subject of PGP through SR, there is still the flaw that buyers get the PGP keys for sellers through SR. The best thing that could be done here is for SR to provide a daily or weekly archive of all of the seller PGP keys so that people could easily compare to see that they all have the same archive, and sellers could make sure that their actual key is the one in the archive.
Yup yup
-
I had a new buyer send me their privnote link as a way for me to get their address and I refused to accept it... am I being paranoid?
Something that forces me to connect to an external URL so that I can obtain an address seems like a great way for L.E. to identify sellers... again am I being paranoid?
-
funway got it right. Great post!
Classical man in the middle attack. To be fair SR could do the same thing during GPG key exchange and this is why measures against this must be taken.
Imo not entirely true, since SR doesn't have the sellers private key. Although could decrypt the message and re-encrypt it with the actual public key... Hmmm. Anyhow, I've never felt really comfortable about the way of exchanging keys (especially when a seller decides to change it somewhere along the way), what would be a good way to improve this?
-
There's no reason to choose privnote over GPG.
GPG is easy enough for young children to use. I don't understand the issues people have with it. :-\
I would be a little nervous about dealing with a seller or buyer that didn't want to use gpg.
-
if opened over tor they will only see your useless tor ip. But i think its used by le for sellers who open up the link by accident in a other browser not using tor. (exposing your ip directly)
-
There's no reason to choose privnote over GPG.
GPG is easy enough for young children to use. I don't understand the issues people have with it. :-\
I would be a little nervous about dealing with a seller or buyer that didn't want to use gpg.
Most people are idiots. Not because they are stupid per-se but rather because they automatically assume they are stupid so they don't even try. Also a lot of people are just stupid. Also a lot of people are lazy as hell. And also most people don't really care about security at all because they think they will never possibly be targeted because there is a bigger fish out there so who cares about lil ol them.
-
A privnote can only be read once. If someone's note has already been read when the intended recipient opens it, they know that something's off.
Other than that, don't assume privnote is secure. PGP is best.
-
privnote url can be mitmed and you will never realize that it was read
gpg public key can also be mitmed though which is why it isn't a bad idea to send it through multiple channels or through a channel where the sender can verify it anonymously
-
yes - privnote can be mitmed. but pgp can't. if someone "mitms" your pgp public key, who cares? that's why it's public!
-
yes - privnote can be mitmed. but pgp can't. if someone "mitms" your pgp public key, who cares? that's why it's public!
you should learn how a "mitm" (man in the middle) attack works before you make definitive claims about it
let's say Alice and Bob communicate over safe-mail with GPG
Alice sends Bob her public key. Safe-mail intercepts the e-mail and replace Alices public key with their own then send it on to Bob. Bob sends Alice his public key and safe-mail does the same thing. Now when Bob encrypts to Alice he is really encrypting to safe-mail, who then can decrypt the message and re-encrypt it (or a modified version of it) with Alices real public key before sending it to Alice.
I really worry the most about instant messages and OTR. I think it would be very trivial for any of the instant message servers we use (or SILC server etc) to MITM OTR keys, and so few people use any authentication / verification methods that it would not likely be noticed.
I have thought of putting out a few exit nodes that SSL strip connections to popular instant message servers and MITM OTR key transfers, just for shits and giggles. I bet I would be able to intercept a lot of communications that people thought were secure. But I am not an asshole so I wont :).
-
Yes, for quick communications involving newly generated keys, mitm is a significant threat.
But in terms of SR, where vendors post their public key and keep them forever, mitm is pretty useless.
-
true which is why I said
gpg public key can also be mitmed though which is why it isn't a bad idea to send it through multiple channels or through a channel where the sender can verify it anonymously
if SR required you to login to see threads, it would be much more risky. Since you can anonymously verify your posted GPG key, it makes it much harder to MITM without being detected. If vendors and customers only transfer public keys via the PM system and not publicly posting them in a thread or profile, it would also be much more vulnerable to MITM attacks.
It's also a good idea to verify fingerprint of OTR keys over multiple channels (different exit nodes, different servers) for the same reason....but hardly anyone does this.