Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kmfkewm

Pages: 1 ... 141 142 [143] 144 145 ... 249
2131
Security / Re: Australian LE Report on BC/SR
« on: September 12, 2012, 03:12 am »
Nice news to hear, however Australia is not at all who we need to worry about.


I mean seriously, try saying the phrase "Australian Authority" without bursting out in laughter. I certainly can't.

Australia has some of the best customs in the world and also some of the most experience fighting internet crime, they also have a close relationship with the FBI and Interpol.

2132
Security / Re: Threat Assessment
« on: September 12, 2012, 02:39 am »
thanks for starting this thread.  Security has always been the highest priority for this operation/experiment/enterprise, or whatever you want to call Silk Road.  From early on, it has been a balancing act and learning experience to engage security experts to improve our systems and practices without opening those systems up to the threat of an attacker.  There are pros and cons and risks to every security related decision.  I see nothing wrong with you discussing these matters here, though.  I'm sure some useful ideas will come of it.  Thanks for your interest.

I am glad that you support this thread. I want to congratulate you on the enormous success of SR and helping to protect so many people from LE. Sometimes I may come across as critical of some of the choices you have made but I assure you that I am extremely grateful that you have managed to bring the internet drug scene to the mainstream in a way that nobody else has ever managed to do. SR is an awesome experiment and I think that it is extremely important that you are not defeated by law enforcement, not only for your sake but for the sake of the future of the online source scene, something which you and this site are now very much the face of.

2133
Security / Re: Threat Assessment
« on: September 12, 2012, 02:35 am »
not sure what is your point. I think treat assessment, have to be sort of dynamic thing based on counter intel.  I think assessment of some kind of abstract treats, is kind of mental  deviation and quite useless. Treat is always concrete, if any.

SR is a game changer, private scene is totally ingrown and shitting on SR profusely, for SR making life for them much more miserable. You can say SR this and DPR that, but what SR is done actually, it educated millions of people about new ways of getting drugs.

I merely point out that in a system which presents infinite ability to register new participatory nodes, there is infinite potential for massive flooding of LE and scammer nodes, and the private scene has found ways to minimize this that SR would be wise to consider. Also private scene for the most part gives not a shit at all about SR and indeed lots of people from older forums use SR.

Quote
Fuck, can you condense that for me?

No, I suggest that if you want to read it you take your fucking Ritalin instead of selling it here.

Quote
-I feel that I get too complacent, even though I do a good job at keeping my real identity and activities unknown. For example, drop spots to me are a must. No matter what anyone says, ordering illegal drugs in your own name, to your own address is never the best idea. I don't care what type of plausible deny-ability you have, if it never comes to your address and the location cant be traced to you, I feel safer.

Indeed, the thought of getting something to an address tied to my name seems strange to me.

Quote
-I think of everyone as a cop. Until proven otherwise, then I still suspect. Every post made, every comment or review is being read by officers who would think nothing of taking you away from your family, job, and current lifestyle. It might just be a little blow to you but, its a felony and a notch on the belt to a cop. I'm often surprised there isn't a sticky reading "EVERYTHING YOU SAY ON THIS FORUM IS BEING COLLECTED AS EVIDENCE BY THE FEDS "

A good perspective to take.

Quote
-I've often wondered if SR has any form of counter surveillance. Just the other night I spent a while mind mapping what counter surveillance for a place like SR could look like. More than 2,500 years ago an old wise China Man wrote about the need for Spy's. I agree. *They have spies amongst us, we probably don't have spies amongst them. That's an issue.

Agreed entirely. The more intelligence we can gather on law enforcement, the better it will be for us.

Quote
-I agree, software sales on the road bring  a huge security risk. As KMFKEWM said, "Windows 7 Darknet Edition" could really be well paid federal agents attempt at infecting and infiltrating the road. Risk outweighs reward I feel.

Indeed it probably is federal agents. It is either federal agents or it is someone who clearly cares far more about making a buck than they do the security of anyone here. If they complain I hurt their business, fuck em, good.

Quote
-A team of "Experts" should be assembled. However, being anonymous in this case can be a bad thing as we should fall back to point #1 and assume everyone is a cop!

yes we should assume everyone is a cop, but having a team of experts will be helpful. Then we can know who to turn to for auditing software. maybe DPR would like to organize the creation of interception detection technology, I am sure some combination of the members here working together could craft a design for these. it needs to be done in the open though, publicly. Also I wonder how many people here have experience with hacking? Let's pwn some LE networks and gather intel. How many here have LE in their family? We need to start utilizing the member base as an intelligence apparatus.

Quote
-I'm very interested in the photosensitive package tampering device. Agreed it would need to be open source. I don't think it would be too difficult. I don't know what parts are available but, I assume it could done using any SoC and basic radio-shack parts. Biggest thing would be tampering.  If its open source, it would be easy to reproduce and replace if the package was nabbed by LEO.  This aspect would need to be hashed out more thoroughly as I can already think of a few solutions to this.  This is pretty basic stuff, no offense but, until you start thinking about tamper proofing, this is basic Hardware Engineering 101.

This aspect is already thoroughly hashed out. The device contains in volatile memory a seed for a PRNG that transmits every so often after a set time delay. Exposing the device to light triggers the photovoltaic cell which in turn triggers a wiping mechanism to irreversibly wipe the volatile memory and clear the seed. Unless the customs officers can remove the device without triggering the photovoltaic cell, or they get better luck than winning the lottery, the idea is sound. We have the theory of how such a device would work and basics about its design completely understood and it is solid, the issue is simply on the implementation details and for that we will need some specialists with hardware and signals knowledge.

Quote
Cashing out BTC and laundering your funds and not doing it correctly. That is by far the biggest threat to vendors using the Road.

I agree that it is a very serious threat to security.


Quote
i am interested in how you would be able to go about admitting new people into private forums seeing as how anybody can be LE.

i have a strong interest in learning about these forums because I fear losing connection with vendors who make my life much more wonderful.  the best i can do now i just collect their public keys, email addys, etc...

If new people were admitted into the private scene, what kind of standards would be required?  i mean, what good reason do all these cyber-vets have to trust me?  i know i'm just a quiet acid-head with positive intentions but what good is that here?  i've been in this business IRL for a long time, but i don't expect my street cred to extend to the interwebs  ;D

this is the only part that sounds like more of a risk than a security measure.  even though i'd love to be in those forums, i'd rather they stay safe so they can pull the strings just right for the public scene.

It is all a matter of proportion. On a public forum where people can register infinite accounts, scammers have infinite ability to register new accounts and so do LE. On private forums with restricted access membership, when a scammer burns one account out they have a lot of trouble to get a new one. With LE if they get 10 accounts into the private forum they will have more trouble to get a thousand new ones than on a forum where they can merely register a thousand accounts, one for everyone in their department. The initial invitation is a tricky subject though. Historically we have brought people over from forums such as bluelight on the assumption that law enforcement had not massively nym flooded it. It might be a safe assumption that the older an account someone has related to drug trafficking, the less likely they are LE, simply on the assumption that at some point in time law enforcement will use automated systems to massively register nyms on open sites, and the ratio of LE to non LE will dramatically change after that point in time. it is a tricky problem indeed, and one that warrants close attention. Public forums are immensely popular and in fact I am all for them even in favor of private forums, but countering nym flooding attacks is a serious priority that is worthy of a great deal of consideration. Perhaps some web of trust will end up being the best way to manage this.

2134
Security / Re: command line gpg - easier than shit
« on: September 11, 2012, 01:28 pm »
hm looks like Guru already explained a lot of gpg command line magic in the gpg club thread, I guess I should have looked through that thread before writing this instead of immediately after.

2135
Security / command line gpg - easier than shit
« on: September 11, 2012, 12:26 pm »
All shell commands will be in code tags. Output from GPG to the terminal will be in quote tags. My comments are simply text.

To use GPG  you need to generate a key pair. This consists of a public key and a private key. It is safe to give the public key to anyone who you correspond with, the private key should not be shared with anyone else. You can think of the public key as being an open lock, which you give to the people who you want to be able to communicate securely with you. You can image it as the people you have shared your open lock (public key) with putting their messages to you in a secure box and locking it shut by closing your open lock on it. Now even they can not open the lock. You keep the private key yourself, in a combination safe. The combination to the safe is your passphrase. After providing your passphrase, the combination safe is opened and the private key is used to unlock you closed lock and take the message out. GPG doesn't actually require that you understand much of this, simply that you know the basics of public and private keys.

Let's generate a key pair from the command line:

Code: [Select]
gpg --gen-key
you will be presented with a series of questions regarding the key you are generating

Quote
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection?

This is simply asking you which encryption algorithms you would like to use for session key encryption and signature. It doesn't particularly matter the selection you make as all of the options are secure, however you will want to select either option one or two as three and four are used for signatures only. I will go with the default of RSA and RSA, so I enter 1 and press enter.

Code: [Select]
1
Now you will be asked the strength you would like to make the keys.

Quote
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

Generally you will want to go with the strongest possible choice, 1,024 bit keys are currently considered to be somewhat secure but they are probably crackable by agencies such as NSA and will not be secure against less powerful attackers for very long. I will select 4,096, which should remain secure for quite a long time.

Code: [Select]
4096
Now you will be asked how long the key should remain valid for

Quote
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Chances are that you want your key to always be recognized as valid by the people you communicate with. I always put 0 here, as I have thus far never desired a key that expires.

Code: [Select]
0
Quote
Key does not expire at all
Is this correct? (y/N)

Code: [Select]
y
Now you will be asked the name and email address characteristics you would like associated with the key

Quote
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name:

For real name you should absolutely put the same thing as the pseudonym you use the key for. Failure to do this will result in pissed off vendors and may very well end up with you being ignored, as nobody wants to spend the time required to figure out which key belongs to you.

Code: [Select]
kmfkewm
Quote
Email address:

For email address you can either put a legitimate (anonymous) email address that you can be reached at, or something made up. I generally make something up, although using a real email address is a good way to keep in touch in case your regular channel of communication is ever compromised.

Code: [Select]
kmfkewm@silkroad.onion
You will be asked for any additional comment that you would like to be associated with your key

Quote
comment:

Code: [Select]
the email address is fake
now you will be presented with the choices you have selected and given a chance to change them if you desire to do so.

Quote
Real name: kmfkewm
Email address: kmfkewm@silkroad.onion
Comment: the email address is fake
You selected this USER-ID:
    "kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

I am happy with all of this so I will select O.

Code: [Select]
O
Quote
You need a passphrase to protect your secret key.

Additionally, a GUI input box may pop up. You will need to enter your passphrase twice. Your passphrase should, at a bare minimum, be longer than eight characters. ideally, it will be an entire random sentence consisting of multiple words with out care being taken for grammatical correctness or making sense.

Quote
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

At this point it is wise to randomly type on your keyboard into the terminal to help speed up the entropy gathering process. This is especially important if you are in a virtual machine, as there is not a mechanical hard drive to be used a source of randomness. During the process of gathering entropy, mathematic symbols are printed to the screen, seemingly for your amusement.

Quote
........+++++

Eventually your key will be generated, as signaled by something like this

note: this doesn't match the key I actually generated because my terminal fucked up. This doesn't usually happen :D.

Quote
gpg: ~/.gnupg/trustdb.gpg: trustdb created
gpg: key 396C7744 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   4096R/396C7744 2012-09-11
      Key fingerprint = 8D9E AFFC C6C9 2BEA 514E  265E 3CF3 2A29 396C 7744
uid                  kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>
sub   4096R/66BDC3F7 2012-09-11

Now that you have generated your keys, you need to be able to get your public key to give to the people who you would like to be able to securely communicate with you. Remember, you use peoples public keys to encrypt messages to them, and they use your public key to encrypt messages to you. Private keys are used in the message decryption process.

let's export the public key

Code: [Select]
gpg -a --export kmfkewm@silkroad.onion
-a signals that the output is ascii armored and --export is the flag to export a public key. You need to make sure to specify the e-mail address of the public key you would like to export or else it will export all of your public keys as one huge ascii armor block. I believe it is also possible to do it by username, however it seems to easily be confused, as when I specified it export kmfkewm it was exporting my real key which has the username of KmfkeWm, but when I specify by email address it works as expected.

Quote
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)

mQINBFBPGkYBEAC+ORsJzjE3AhgWXS9MplXQMYe8JqCjmIzp9tTu5t+v8OlS2ibx
WqFPCsP/gD+lumnPy9zhwC1TnspcXdU8kfepK5xsrKBfGzBJ17kdkdsgAR5yQOj3
uO1thsI8e9diJaSPfJofNpsWHi93gNUNRyp+W128QebwOIMnMkF35s3X2nqKlY4O
NBXEIUBtEiI7D+qVWONLrdH9OXpOAJVYXBqFA+azF+isebLZ2TC1wrU5edMPGt1d
K9DPn7BSc3fOsIj6eR316if7Qu6dG2By9jG6ZVV7Ffvovw0tgeiQbm2aJMHdm3MU
NMrALmb6mxhgn3nYqkNFqX7UfKY3QF2ewaynseqliBEUtEDLHzD+93PT6+/jDyjS
LOc8ZUDIobfeUlk8TxwBGf6XG/o3Jca/6Ae3oRuFyLYM+yYmaQwldEaaVHn1AQPx
GpxEvoJ7Yfl7tbafCA5RBZ79x7kaslJiC+bh9yEzconof56H/awNHBrQUJB+vGjT
VjaErCsTOgE2vjPIwRvaZKo71s/tFXpw0wUd3owxoKr29dvQKgJRXycuikk8kJWF
G7WFpHlpYBiuLCKNFIIzeBX2FsvK3JVywMVlPXO1nkNJcjzTOpmhSm4Rei2btgql
aiKUax+elHE0aEGrt/zuAKkRVtaOQ483ZH+jkssaAuduAnoAX5ANfgp/ZwARAQAB
tDxrbWZrZXdtICh0aGUgZW1haWwgYWRkcmVzcyBpcyBmYWtlKSA8a21ma2V3bUBz
aWxrcm9hZC5vbmlvbj6JAjgEEwECACIFAlBPGkYCGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAAoJEGReY/Kkoi17n4kQAI505WN2FodXMZlU+aOfNep9k4bIeV41
NRMqOLDqip0nzL05ZsbP9cvpHdsMlSZ7DHwQ9L7ms7EhKACeHK1X6Ens13N1RNOH
cVGuiZERMKM/Jpc7M3GEIfhSK0tTzGKVi33Iwc0EGYkqYGAGFSfx0awhs/qVBxDp
ja0/cf+PeBkGOeb3DgHnQBJ+JG/l3KmQIa0T4/e1g71pL1InvSdA0YsLuxglCrMZ
T+hDo1lPdmuUjLRahrHw29eNtJsH6wkyfC7fmpDwdwwy9bfE9H0tI9zFnrJ7xyy2
yMWxaoPIkrWHXuAqHqXpCqljy4J+Yi85o2KbnZwRiKFVj9kYQYyjEEa4C/WMkYxp
6JLGaNpReK0KurJiSBa0fpjRvMN8zaEdkHNEtSwbJV2c8aFuHYvlA8ForjPT3kZ7
qrDGMVe7b8BkF82XTLvTyFZ6n+1T9fXTZjTlwHWr3xjrXoRjNH4Y/sgwWEU681WV
Ct9Q5l1ecyq3NrhVQWsZp3Mfm9EwFxN1i55uccQtZSomEsQ+e7XsExSB6fPtdPHA
WU4Hcphjyx5T4rRats4Mj3B+KH5lRNRJdGM9s9nX/1c/CQ+vg1eqifJvyjI2jvYW
HXW/J3iOSp4woRNPKPJy0YMbDMFevMOQ4M9JFkOoH+CQ4VLWTdMKPaaIosPRofm+
7JpQGJeAH1b2uQINBFBPGkYBEAD5+/TrHjszZzX58ajyJEedU1AB53P3yPrwKmH8
jnU6cLtn4mj4hhothKckVSReJkr6nuHc6CfWG1AUBxhcS4PNg8Otn/HK6/HvWnL9
hsqXxs9D9h0j5TNzoCNCGsYmjDWkClOHqSwZBvrROvmzAbMbIYWQls8JXRyArF4U
Fb7szRSfuQUEAgHkqBV54bUm/Dt5SIZgp1DhIIoeXaQptvE13pnBnuE4en0hBqTI
ZcYb+eyCjeAnXjztl6JX418k4GRbWMIYjK3Gu1QHKLhyhaFpk5awGkHUAwmPk1wd
hdiQacBQKrv2//23Qx6Ad7W+RtpsjlcxoMivrHJbZ4m54zqlP/ZJDSUcq9zLo/+/
r3eo7nv8qTUUNDKOL0VJUgH2a+th1RwFqxjf+q4BSRwg+YzQwMVlX9EUntj1ZW7o
c2K1AXciVb4cov5m6xUz8pSrVXhCEkLixaNfYGv14dCwJFVszIMAwTi5Lrdo+g/4
P1Nj8Ttg32lq5gyCNgKj4wrkCDGeaj7o32AwhfhB9hTPJQfLi6D3N7XtNS6e2YME
a5+WXklgxbWgMJvu4+zBNvgzzNNxMpgZVp3ScPKSPQI6ehLzuXtRcH8xUGPS/02b
tSoFz24bXS+kzzM7YraV+opy7g0Vrq++CeUKLg83qafscc6UW235VjTkc6UzVFHu
KHLtiwARAQABiQIfBBgBAgAJBQJQTxpGAhsMAAoJEGReY/Kkoi17Rl0P/jeafez9
vRVQYLi/7cuxXC25Shiu/D3/19ucaOTQRmWEYXbLYTqS7IaeI80POh+FwTqye7gg
3zW1O3cBGTyups44vvDJWbwTl8G3sMK/dSP3QWoThq1ooNzi9+MWahXWtmj2qJBn
UJh0fnFMzPEK0EYWWdwX+crffiUmM9fNC2qDP/WZXMWbXEHqFcjDrrq3mFWYKMSD
5jUM8o3yMngUoa4+VN4G9KbqbF91CzSnOSlwpVUIkwFOv1C3iBcAgj8lHGD+Zv18
V+uayZSSwek7w84w1oiTtfRPxPUrsuexA07jkh0F4YQFkbWaIPUFuekRwwl1thT5
nRe/IsxIXh/Qfcnrf5uuxM0gVjNh1RvgyqgmCo361odX329hL4wY/OKcppVXbmnr
kUEQROvbPIZYG5mJlr12HXvZ67hQlWLUVw/w6zoPSkq2+pP+x72WCwnodwLXw6Uw
vMSz0ZDSDAVJ6kSGuxp/nvsMMQA004rIJInbDx4f/uGbUm0GbTpbMxb/SWPRqgcn
KRn0ZtkY9e+nTvGRMiahNQ/p2F77jVgVZYTM7QC2sDdQYFeJHQDGEX3HZANK51/5
FcUwaMMUYbDZFfrLL6aLUbJvVX/vl+qIUMmZTKhqNQSICIWD2NJ8VqdMhfgIviFQ
BTMSc5GKuWYmpdkX4xwW+hWbPY0ZTP8F0wsa
=IZ3p
-----END PGP PUBLIC KEY BLOCK-----

When people want you to be able to send them encrypted messages they will send you a copy of their public keys and you will need to import them. This is an easy process, feel free to test it with the key I have listed above. First, copy the key so that it is in your clipboard.

Code: [Select]
gpg --import
now paste the key to the terminal.

Code: [Select]
ctrl d

note: ctrl represents the ctrl key, you do not type it in.

Now that people have your public key, they are able to encrypt messages to you. Also, now that you have their public key, you can encrypt messages to them. Let's encrypt a message, in this case I will simply encrypt the message to myself.

Code: [Select]
gpg -e -a
Quote
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line:

Allegedly you can specify users by username, however the same issue with kMfkeWm vs kmfkewm seems to be present, so it is best to select users by their e-mail address. Alternatively, you can select them by their full user ID. Let's take a moment to side track the current train of thought to show how to get a list of the full user ID's of people whose public keys you have:

Code: [Select]
gpg --list-keys
Quote
-------------------------------------
pub   4096R/00E5A93C 2012-08-25
uid                  KmfKeWm (lol) <kmFkEwM@kewekeke.onion>
sub   4096R/E075FB13 2012-08-25

pub   4096R/A4A22D7B 2012-09-11
uid                  kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>
sub   4096R/930F85D3 2012-09-11

The UID consists of everything after UID up to and including the closing >

so let's get back to encrypting messages. Since it asked my for the UID of the recipient I wish to encrypt the message to....

Code: [Select]
kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>
Quote
Current recipients:
4096R/930F85D3 2012-09-11 "kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>"

Enter the user ID.  End with an empty line:

At this point I could select to encrypt the message for multiple recipients, however I do not desire to do this so I simply hit the enter key with a blank line to signal that I have selected all desired recipients. Now type your message in

Code: [Select]
test
Code: [Select]
ctrl d
Quote
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQIMA4foEHyTD4XTAQ/+OH12e/1CQRnjivuthCIWXUMEr3QJDW8QdPEXv5dhmVte
awQi+OUGK8oHJUv2ydrpQJdR4V4RTSiZL3r94bD+04dwxZG7Yi+TZ7//GQ21hPua
l0Dgg6G/aNZH8cn0HQRFwOY7butvMgkB1I52j/CAaMHtRJaIwtRx+56k2M6CZSRu
Su14MUm7Yv0mg0itrd9i+vNb3298ZGIE9x5BeC0rh/3P+Sng+9c8v9cPJPaDHr8m
aZp6y6CgzlGoy6dzBpKpA3HdfR4wUgW+YOmVkWAVQldKnBkcEHsLdEwqwzmD8k3l
QJtOfyLbVQhaVvacEMvSNIHGpYm55FSwG0RtIje+QosLZgBku+GOYWtT/92tDm1j
oHNr9fAkNB8KMbYyHHz7IjFhYExuF+Fes0gocRDfJ0MArUHD0OSsYQDIWMBvRbFe
F4KHDKkEr6/bMGB4NPZD69tSw0y96+VELcwEbKmgXcmKlDay5jEFkjptiX6nKpzC
gPZQUsj2bz/0jZRLRa4fjOWeDKkyhQzXtHndMVnWNjCQyJKaBU9PTHkmQ9cbWeM7
uvpVWgpGEzEL7qsmXs5EHd7C3JVLLdC3cRgsxJVIwz/vUOPdjT/xRgRIZjOAFXUb
XdaJpoATCySw8KpNYn1XQGlg6bXTI+dpuEZSXPbe1bci5hzf5QkU5sLRhxFYVJTS
QAGSmEaDsTCVD5VDL2C5xvtHgeG+GVwRKRTEFvwm6wcikcoqD8p+IpgdUg5jcd4i
L3M4RQ/EHceD4IWn7EXBGiY=
=XBGa
-----END PGP MESSAGE-----

This is the ciphertext, and it has been encrypted to my key. Of course, it will be encrypted for whoever you selected when you entered a UID.

Sometimes you will get encrypted messages and need to decrypt them. Since I just encrypted a message to myself I will now go through the process of decrypting it.

Code: [Select]
gpg -d
You are presented with a blank line. Simply paste the ciphertext that you wish to decrypt

Quote
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQIMA4foEHyTD4XTAQ/+OH12e/1CQRnjivuthCIWXUMEr3QJDW8QdPEXv5dhmVte
awQi+OUGK8oHJUv2ydrpQJdR4V4RTSiZL3r94bD+04dwxZG7Yi+TZ7//GQ21hPua
l0Dgg6G/aNZH8cn0HQRFwOY7butvMgkB1I52j/CAaMHtRJaIwtRx+56k2M6CZSRu
Su14MUm7Yv0mg0itrd9i+vNb3298ZGIE9x5BeC0rh/3P+Sng+9c8v9cPJPaDHr8m
aZp6y6CgzlGoy6dzBpKpA3HdfR4wUgW+YOmVkWAVQldKnBkcEHsLdEwqwzmD8k3l
QJtOfyLbVQhaVvacEMvSNIHGpYm55FSwG0RtIje+QosLZgBku+GOYWtT/92tDm1j
oHNr9fAkNB8KMbYyHHz7IjFhYExuF+Fes0gocRDfJ0MArUHD0OSsYQDIWMBvRbFe
F4KHDKkEr6/bMGB4NPZD69tSw0y96+VELcwEbKmgXcmKlDay5jEFkjptiX6nKpzC
gPZQUsj2bz/0jZRLRa4fjOWeDKkyhQzXtHndMVnWNjCQyJKaBU9PTHkmQ9cbWeM7
uvpVWgpGEzEL7qsmXs5EHd7C3JVLLdC3cRgsxJVIwz/vUOPdjT/xRgRIZjOAFXUb
XdaJpoATCySw8KpNYn1XQGlg6bXTI+dpuEZSXPbe1bci5hzf5QkU5sLRhxFYVJTS
QAGSmEaDsTCVD5VDL2C5xvtHgeG+GVwRKRTEFvwm6wcikcoqD8p+IpgdUg5jcd4i
L3M4RQ/EHceD4IWn7EXBGiY=
=XBGa
-----END PGP MESSAGE-----

you will likely be automatically prompted for your password at this point, possibly in the terminal or possibly in a pop up GUI input box. Enter your password. To view the decrypted message you may have to hit ctrl d

Code: [Select]
ctrl d

Quote
You need a passphrase to unlock the secret key for
user: "kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>"
4096-bit RSA key, ID 930F85D3, created 2012-09-11 (main key ID A4A22D7B)

gpg: encrypted with 4096-bit RSA key, ID 930F85D3, created 2012-09-11
      "kmfkewm (the email address is fake) <kmfkewm@silkroad.onion>"




test


That sums up the basic commands required to use GPG from the command line. Of course you can do a lot more with GPG, symmetric encryption, hashing, file encryption, signatures and validation, etc, but I am not going to cover all of those unless people specifically request that I do. I hope that this shows that using GPG from the command line is trivial and that using GPG in general is trivial. I believe that this tutorial is fully cross platform. You do not need any fancy GUI or OS specific bullshit to make full use of GPG, and in fact I find that controlling it entirely from the command line is far less of a hassle. It is also far more secure as now an attacker sending you malicious ciphertexts can only hope to exploit a vulnerability in the core GPG engine, instead of the GUI package or wrapper you are using for GPG.









2136
Security / Threat Assessment
« on: September 11, 2012, 10:40 am »
In this thread I would like if we bring up and analyze likely threats to the security of SR and the participants engaging in the market here. Let's discuss the vulnerabilities that law enforcement will likely attempt to exploit and brainstorm and present ways to counter them. I will get the ball rolling.

One thing that I enjoyed about OVDB is that sellers had trust status assigned to them and all of the trusted sellers had reputations on private forums to be concerned about. One of the most glaring vulnerabilities SR has is also one of its strengths: anyone can become a vendor and the price of becoming a vendor is relatively cheap as compared to the amount of customer intelligence that can be obtained. As DPR has no presence on the private scene, it will be difficult for him to implement such a system. Additionally, such a system indeed opens up further vulnerabilities: if the person who assigns trust becomes compromised then the trusted vendors will all eventually come to be compromised, at least all additional vendors. Additionally, Tarpaulin and Fairydae clearly show that trust is not perfect security measures, even when long standing difficultly obtained reputations are on the line. I do believe that this sort of system protects from federal infiltration more than it does from scammers. Still, it seems foolish for us to not take advantage of the long standing reputations and history of the private source scene, especially when several of the vendors here have some history and reputation on established private forums. Additionally, the feedback system here is seemingly easily gamed. Some additional system of trust and reputation should be implemented here. One idea is from Undrugged, a site some of you may remember. I believe a similar system is in place on SafeorScam. The system is simply a variant of a web of trust, where participants can cryptographically say how much they trust other participants. A great deal of care must be taken in assigning trust, because if you say that you highly trust a person who later turns out to be a federal agent or scammer, the amount of trust others have in you will be diminished. In fact, I believe that it may be worthwhile to pursue a software system that makes the management and visualization of WoT easy for participants here. This will possibly help us to identify organized scammer and law enforcement infiltration: after one such infiltration is identified we can be more suspicious of the 'nodes' which have assigned trust to the infiltrators. 

Of course the primary threat to customers is that their order will be intercepted and result in a CD or raid. We have long discussed the possibility of interception detection technology, and I am strongly of the opinion that obtaining an easily implemented open source design for such technology is something that should be viewed as a top priority. Perhaps we can find people on SR who have the required skills for such a thing and form a sub group dedicated to the implementation of this technology. When coupled with fake identification or other non-linkable boxes, interception detection technology can potentially remove the risks associated with package interceptions, this would be the single greatest increase possible for the security of SR customers. The entire process of designing this technology absolutely must be publicly viewable and real time.

Another thing I see as a serious threat to security is mis/dis information. This is false information, either unintentionally or intentionally introduced, respectively, in an attempt to degrade the security of participants. Misinformation may come from participants who want to help but who are themselves not as knowledgeable about subjects as they think they are. I see this frequently, users give what they think is good advice but in reality is bad advice. I see this even more on some clearnet forums where even the administrators suggest that people stay away from Tor and instead use VPNs. They may say things like "Tor exit nodes can spy on traffic, you should avoid Tor and use VPNs". This is not applicable here as Tor is essentially required to access SR (in between sites like tor-proxy aside), but is a good example of what could be either mis or dis information. In the cases where this is misinformation, it is largely due to lack of sophisticated security knowledge on the part of the person making the claim: chances are they have read some news article that discusses Tor exit nodes spying on traffic, and have jumped to the conclusion that Tor is not safe. Of course someone with appropriate security knowledge will recognize that VPNs are just as vulnerable to exit node spying as Tor is, making the suggestion at best being based on an incorrect comparison between Tor and VPN's. In the case of disinformation, it will be a federal agent making the claim, possibly even suggesting specific law enforcement agency owned VPN's that ought to be used in place of Tor. Unfortunately mis and disinformation tend to spread at exponential rates, a naive user who is presented with mis/disinformation will tend to take it at face value, and in an attempt to be helpful will propagate the mis/disinformation to other participants. Of course this can be devastating to the security of individuals and even to entire communities.

I would like us all to think of ways to combat mis and disinformation here, but I will present a few suggestions. First it would perhaps be helpful if some users who are widely recognized as being security specialists are given special titles identifying them as such. More value should be given to information coming from them than information coming from people who have not been recognized in such ways. How we can safely and fairly identify such users is a matter that warrants further discussion. Also, in some cases even experts have differing opinions, we need to recognize this as well. Furthermore, it could be exceptionally dangerous if law enforcement manage to gain control of accounts that are titled in such a way that trust is assigned to them.

Another potential way to counter mis and dis information is to expect that citations be included for any claims regarding security, at least where it is possible to provide citations. Additionally, perhaps threads should exist for security discussions where all substantial claims are required to have citations backing them.

Another major attack vector is in the software suggested to users. Without any doubt law enforcement are going to be providing "secured" virtual machines that are actually backdoored. I suggest that the sale of virtual machine images and similar be banned on the silk road market: there is no need for these services as independent secured live operating systems already exist (see Liberte and Tails), and the the time and skill required to audit an entire live operating system is such that we can safely assume that none of the live operating systems offered for sale on the silk road marketplace will be audited. Software is another area that is ripe for exploitation, and although I have previously said that we should not ban the sale of software I now have changed my opinion. I believe that sales of software should be banned on the silk road marketplace, or that we must use a strict auditing process. I can clearly see a benefit to allowing users here to offer software that will assist in the security of vendors and customers, as well as generally make life easier. However the risk of law enforcement exploiting this by encouraging vendors to use restricted access backdoored software is far too great. Software made available through Silk Road absolutely must be open source, publicly available and audited. Preferably we could find how many of the users here are fluent in different programming languages, and create teams of people who audit software. The people creating software are not barred from making profit, nothing stops people from donating to their efforts. One could easily say that this is counter productive to the spirit of a free market, however the fact remains that software distribution is a major attack vector, and I believe that our security is more important than the right of a person to sell software here in a restricted fashion, indeed the model could not be worse than one in which the only people buying a product are the only ones incapable of properly auditing it. A million arguments can be given for keeping closed source or restricted access software available here: vendors could be using advanced security techniques to isolate said software (realistically, almost none of them will be), vendors could independently get the software audited themselves (realistically, none of them will), it is up to the buyer and their responsibility if they are successfully exploited through this attack vector (true enough, but if a vendor is exploited in such a way all of their customers are put at risk, as much as it goes against my beliefs regarding other things I truly believe that regulation for the good of the community is acceptable in this instance, there are far too many vendors who do not appreciate the risk of running unaudited software and far too many vendors who naively trust anyone who makes enough posts and seems friendly).  Additionally, it does not violate the principles of a free market if DPR opts to restrict the sale of closed source and restricted access software: it is his marketplace and he is free to do with it as he pleases.

I believe that a culture of paranoia is essential for the ongoing security of the silk road community. How we can instill such a culture is an open question. A great many of the participants here are naive not only to criminality (most having probably never participated in an organized crime enterprise before, or having had many run ins with authorities), but also to technical security. Particularly it is important for DPR to have mistrust of everyone. I believe that if he places trust in others, that eventually he will trust a malicious party who could do damage to the silk road community. In the past I have seen him engage in activities that strike me as being somewhat naive, offering positions of technical privilege in the form of job offerings (in fact even I was offered such a position fairly early on, based off seemingly nothing other than my apparent skill with server hardening). It is in the best interests of DPR and SR to consider that everyone participating on SR is a federal agent. On the other hand it is also clear that he will need assistance with securing and maintaining silk road. I strongly suggest that he creates a thread for brainstorming and technical assistance in regards to SR, and asks for any help in that thread, to be thoroughly analyzed by the larger community and implemented by him and him alone. every additional person with privileged access to or information regarding the SR server is an additional attack surface for law enforcement to target, every job opening that offers access to privilege or information is a potential opening for federal law enforcement infiltration. He will be wise to recognize this, and to assume that all participants here are interested in deanonymizing him and compromising SR.

Public sites are important, centralization is bad, compartmentalization is key. Nobody can doubt the role of a large public site such as SR. SR has single handedly transformed the online drug dealing community from a comparatively small community to a mainstream phenomenon. Indeed this is a key event, somewhat of a tipping point if you will, and in fact in line with the Netwar theory of such groups: that they will start small and eventually grow to the point that they spiral out into the mainstream. We should always have a public marketplace. That said, having a single point of failure is bad. In fact there are an abundance of private forums and the world of online drug trading will not go away if SR falls. However, I believe it is important for people here to branch off into private forums with restricted membership. There are several advantages to this. For one, it will help keep communication channels open in the event that SR is severely compromised. Even on tight knit private forums, an act such as being hacked or shut down can fragment membership and lose participants as communication ties that rely on the centralized node are cut. An additional benefit is that restricted membership forums inherently grow more resistant to scammers over time, if a private forum consisting of 600 participants on SR is created, as scammers start to be identified the ratio of scammer to legitimate accounts will grow in favor of legitimate accounts. On a public site such as SR, scammer accounts are a fully renewable resource. Even infiltration by law enforcement can be stymied by implementing restricted membership private forums: on SR mass registration of law enforcement accounts can go on indefinitely but on the hypothetical private forum, the ratio of legitimate to law enforcement accounts is unlikely to change much from what it initially is. Additionally, if small groups from SR splinter off into private communities, there are techniques to reduce the damage of even multiple law enforcement infiltrations: requiring multiple people to vote on all new members and keeping records of who votes to grant membership can quickly identify topologies. The effectiveness of this may be limited unless law enforcement nodes can be identified.

Additionally, communications technologies that inherently support compartmentalized and massively distributed group interactions are important. Thankfully a great deal of development time is currently being spent on such technology.

Another thing I would like to mention is the role of intelligence in such an organization. The importance of this is frequently overlooked. It would be strongly beneficial if SR could rally hackers friendly to the cause to try and pwn law enforcement personnel, intercept their communications, identify the law enforcement accounts on SR, etc. All forms of intelligence gathering should be employed against our enemies as information is what wins wars. of course securing our own information is of utmost importance, addresses should be encrypted, hardened systems used, Tor used, great care taken in protecting our shipments from being flagged, etc. However, defensive security is only one half of the battle, and it is equally important for us to gain as much intelligence on law enforcement as we possibly can.

The strength of a public site like SR is certainly in its community. Utilizing the community to its full potential is important, and this importance is reflected in several of the other things I have discussed in this thread.

Another thing we must always be careful about is becoming complacent. We must always remember that we are engaging in illegal activity, and that it is the job of law enforcement to hunt us down and imprison us (of course it being their job does not excuse them from responsibility, and they should be harshly punished for their crimes against humanity). All too often I see people here who seem to have forgotten this. When I see posts from people wanting to use credit cards to pay for their drugs here, it makes me cringe. We should never let convenience out weigh security, and we should never forget that we do indeed need security as we are engaged in highly illegal behavior. This is not E-bay, do not be confused by the friendly nature of this implementation of drug trafficking into thinking it is anything other than drug trafficking. Don't be fooled by friendly posters, the federal agents are sometimes the ones you least expect.

2137
Quote
Yep, I've demonstrated this a couple of times already.  It's a function, though, Python doesn't have anything like Ruby's put command (no, I haven't learned the language, I just looked at the Wikipedia page on it).

just a wild guess but maybe something like printf("what to put \n") will work ;).


Quote
Which brings us back to proving it, which we've been round and round on.  Your comment there wasn't merely pointing out what might be, it became an accusation at that point.

I never accused you of having a similar backdoor in your code, I only said "hey look, I guess not having networking code in the program isn't as strong of proof that it is not backdoored as you thought"


Quote
Axtually, what you said in response to Limetless' question asking about your code and for proof of my engaging in some kind of deception was this:

Which is 100% true. It is stupid to buy a script if you don't know what it is doing and it has not been checked out by enough people who can figure it out. If it is posted publicly anyone can check it out and any backdoor will be quickly found. I could ask a dozen people I know who know python to look it over and let me know if it is safe or not and pass that on to the forum. I am sure a lot of people here either know python or know people who do, and that they could do the same. I point out that it is not necessarily obvious if a script is capable of transmitting data over the internet, that is all that I demonstrated. Even you couldn't figure out what the script was doing until I correctly commented every line of it, it seem that you actually thought the initial bullshit comment I left explaining away the call to unpack was legitimate, even when I intended for my initial post to clearly demonstrate the backdoor. Do you think someone with no programming or command line experience is going to be able to find what was going on there, or will they think it looks innocent and be satisfied with the detailed if partially incorrect (intentionally so) comments I left?

Quote
That pretty clearly states that because you thought of a way to conceal an exploit in a different language that therefore my code will 100% guarantee that users of it will be compromised.

No I said 100% of users who use your software will not be able to identify something like the backdoor I demonstrated in a different language. Because if they could identify it they would program the tool themselves. The solution to keep everyone secure and happy, is to get donations for your work and let the code be publicly audited, because I guarantee you if I read the Ruby script I wrote but someone else had written it, that I would have noticed what was going on. Someone who knows Python but not Ruby looked at it and had a difficult time to figure it out even with most of it commented correctly, I think that goes to show that you should know the language well enough to audit code or be confident that others who know the language well enough to audit code have done so, before you run scripts from anyone.

2138
actually I don't think it will work with --decrypt-files because the output is handled differently, I think it it would indeed take more code to do it with that flag being used instead of -d.

2139
Quote
I'd have to add a lot of code to achieve that with my current effort.  There is no way to conceal that something was occurring between the decryption and the parsing of the decrypted data to produce a printable file.  Especially not after stating that the bash command was just the GPG command (i.e. gpg --decrypt-files *.asc) and doing it in Python is this:

Code: [Select]
os.system("gpg --decrypt-files *.asc")

it seems to me that you could just do this instead

os.system("gpg --decrypt-files *.asc | some_(obfuscated?)_way_to_run_the_output_as_a_script")

although I am not sure if python comes with something like ruby's irb that would allow you to pipe a script to it to be immediately launched.


2140
Security / Re: The ugly truth about security software
« on: September 09, 2012, 10:50 am »
If you use no anonymity solution you still have a chance of remaining anonymous in the sense that your IP address may not be linked to your identity. Law enforcement have limited resources, and in fact are only capable of following up on a fairly small percentage of the IP addresses they have identified engaging in illegal activity. Since ISP's only keep records of who is assigned a certain IP address at a certain time for a certain amount of time, if law enforcement does not get around to following up the lead involving your IP address before the record of who the IP address was assigned to is lost, you can maintain anonymity. However, your ISP is capable of seeing every website you go to (if they look), and every website you go to is capable of seeing your IP address (but possibly not using it to determine your identity). You should certainly not expect to remain anonymous from interested parties with any significant capabilities whilst not using any anonymity solution, but it does happen all the time (generally due to overloaded LE resources, which they generally but not exclusively focus towards higher priority targets).

If you use a single hop anonymity solution the situation greatly improves. The websites you visit now can not immediately determine your IP address but rather see the IP address of the proxy you are using. Likewise, your ISP can no longer trivially determine the websites you are surfing, they (ideally) only see that you are connecting to the proxy. However, the proxy provider can see which websites you are surfing to, and so can its ISP. Also, the proxy may keep logs which can be followed up on. Also anyone monitoring the proxy is capable of getting the same information that the proxy gets.

If you use a double hop anonymity solution the situation improves even more than before. Still your ISP can not see the websites you surf, only that you connect to your entry proxy. Also, the websites you surf still can not determine your IP address, only that someone is using your exit proxy to visit them. Now you also have the additional benefit that the entry proxy does not know which websites you are surfing, only that you connect to your exit proxy. Additionally, the exit proxy does not know who you are, only the websites that you surf. Ideally the ISPs of the entry and exit proxy will be different and will not be able to link your IP address to the websites you surf either. Also, now an attacker starting from the website you surf and trying to trace their way back to you will need to get logs from two proxy servers instead of one, and either of the proxy servers might not be keeping logs or not keeping logs long enough to be of use.

If you use a three hop anonymity solution, the situation improves a bit more. Mostly it is the same as using a two hop solution, however now the entry and exit proxy do not know the identities of each other, only the identity of the middle proxy. Now if the entry proxy is run by the US feds and the exit proxy is run by the German feds, even if they have logs that could be used together to deanonymize you, unless they routinely share intelligence they will not know to get in touch with each other regarding specific packets unless they can learn each others identities via the middle proxy. Additionally, an attacker starting at the website you surf and trying to trace their way back to you with log files, needs to get logs from three different proxy servers that may not be logging and may not keep logs for long. Now the biggest attack that you need to worry about is an end point timing correlation. And attacker who can see packets coming from you and packets arriving at the website you surf can use statistical timing analysis to determine that the packets they see in both locations are 'the same', thus linking you to the website you visit.

Past three the benefits of adding more hops very rapidly decrease. The end point timing attack continues to work regardless of the number of middle nodes. Adding additional nodes only really adds additional protection from an attacker who starts at the website you visit and tries to use log files from each proxy on the path back to you.

So the difference between using no proxy and a single hop proxy is huge, the difference between using a single hop proxy and two proxies is tremendous, the difference between using a two hop proxy and a three hop proxy is significant, and after that the benefit of adding more hops is minimal.

2141
Quote
Every time a vendor has to make a reply to a customer, they have to burn data to 2 read only DVD/CDs. Once to find out what the message was, once to make the reply.

Actually at least in one direction they would need to hand type the information over. Using DVD's in both directions would break the air gap.

2142
Quote
By the end of next year Ruby will be 18 years old, nearly old enough to drink (in most places) and it still doesn't have that.  Wow.

Ruby does bytecode but in most implementations of it there is not a (easy , or intended) way to launch programs directly from bytecode. Also I think Ruby is 20 years old not 18.

As far as how many people here know C and can audit it, I assume quite a few actually. I have had no problems finding a whole lot of people to look over any of the code I have ever written. We are on a forum on the darknet where everyone uses crypto, there are probably hundreds to a thousand professional and hobbyist programmers on this forum.

2143
Quote
Does the trigger string need to be part of the code or does it just tell the existing code to activate?

It needs to be part of the code, I included it as a comment so that it has no effect on the script but still signals to the original script that it should pipe the plaintext to irb.


 I'm assuming you mean the former, but I just want to clarify (since I don't know Ruby and don't know what your code snippet actually does).

Quote
Well, if pack in Ruby is what I think it is, then to do the same in Python I'd have to import struct (and probably array too).  I've already said several times what modules are imported, so there goes that.

pack changes how data is displayed. For example I could unpack the string "see" into binary representation : "see".unpack("B*") == "011100110110010101100101"
and I could put that in an array and pack it back into a string ["011100110110010101100101"].pack("B*") == "see"

so when I say

puts `echo "#{decrypted_message}" | #{[105, 114, 98].pack("c*")}`

it is equal to saying

puts `echo "#{decrypted_message}" | irb`

which means that the decrypted message should be piped to irb which is a command line style tool for running ruby scripts.

I could also have said this:

puts `echo "#{decrypted_message}" #{["7c20697262"].pack("H*")}`


Quote
Hell, there are only two files with integers in them (to read data in each row of the CSVs).  Well, alright, 5 files if you count the one with a number in the name and the two files that invoke it.  Obviously in the case of those three files the number is part of a string and not an integer.

These numbers are strings also, anything in " " is a string.

Quote
Plus if a vendor is using an air gap all the networking code in the world won't do shit.  Yes, I know buyers are lazy and probably don't, but the paranoia of dealing makes an air gap a greater possibility.

And if we wear bomb proof suits we can jump on hand grenades.

2144
Security / The ugly truth about security software
« on: September 09, 2012, 08:46 am »
The people selling pre-configured virtual machines and OS on USB memory stick packages here have approximately a 99.99% chance of not being qualified to properly secure a system.

Approximately 95% of people who are not properly qualified to secure a system think that they are properly qualified to secure a system

Approximately 100% of federal police agencies would try to get vendors to use their virtual machines with bugging software in them, it is a real attack vector to worry about

There are already free operating systems that can be installed to USB memory sticks or used in virtual machines, such as tails and liberte. These are much less likely to be backdoored and although they are not professionally hardened they are very likely to be better than anything you get here.

____________________________

If someone wants you to use their bridge or suggests a VPN service to you, they have a 95.51% chance of being a fed

No matter what, if your entry and exit traffic are monitored by the same attacker, you are deanonymized. Adding more hops results in rapidly decreasing anonymity gains. One hop is a tremendous improvement over none. Two hops is a tremendous improvement over one.  Three hops is a significant improvement over two. Four hops is a very slight improvement over three.

People who sell VPNs generally don't have a fucking clue what they are talking about.

A huge number of VPN services keep logs, even if they say they do not.

____________________

Your Anti Virus and Anti Spyware are not good enough to detect viruses or spyware custom made to pwn you.

_____________________

Watch out for sales people. Any jackass with a bit of experience can throw together something and sell it as the best thing since sliced bread. This happens a lot. A lot of them actually believe that they know what they are doing. Don't trust sales people with your security. Don't believe what you are told, research yourself, and please don't research through the resources made available to you by people selling shit.

This is not to say all products that are for sale are insecure or bad. It is simply to say that I want to vomit when I see people selling 'ultra secure virtual machine images!!!' on SR.


2145
Rumor mill / Re: UglySurfer's Darknet Extreme Virtual Machines
« on: September 09, 2012, 08:29 am »
they are 0% secure.

Pages: 1 ... 141 142 [143] 144 145 ... 249