Computer Security (AKA: prepare yourselfs for more underground forums)

My honest respect, definitely the most sophisticated design I've come across so far (regarding drug forums). I think I was too quick (and too ignorant) to say that such systems don't exists. Perhaps they do, they are just a well kept secret. When freedom of speech has become nothing more than a memory there might be a real demand for such systems. Right now I (perhaps naively) believe, that simpler solutions, discipline and responsibility might be still sufficient.

I had something far less complex in mind, honestly I have never thoroughly thought about it and now that I'm struggling to put the ideas into words the flaws reveal themselves. Anyway...I thought about a client side application too, but just as some kind of simple board viewer that stores a list of all the board's member's public keys. The user would type his message in a text-field and upon submitting his message it is encrypted with GPG (multiple recipients). In turn, if a member wishes to visit a thread, the ciphertext is downloaded and decrypted with GPG (at least PGP allows the user to store the pass-phrase for a specified period of time, this would be more convenient but also less secure).
In this case the server is nothing but a storage facility that stores and organizes the cipher-text-threads. No additional server-side functionality would be needed.
The drawback is obvious. This works only as long as the number of members remains unchanged. If a new member joins the community, all messages need to be "re-keyed".

But even if the applications are kept as simple as possible, it still requires a good amount of work. Not to mention that every software after it's initial release contains flaws, bugs, vulnerabilities and it takes time until it has matured.

 

as an added layer of security people should have a offshore bullet proof server shell that connects to that and then the server would connect to all the questionable sites

 

The thing with encrypting to multiple keys is that it gets very huge. Encrypting to two keys creates a text block as big as encrypting to one key twice. If a forum has even a hundred members, posts encrypted to all 100 of them are going to be huge even if they are only a single character once decrypted. Tor goes very slow and wouldn't handle this well at all. Plus no new members could join with out mass decryption and re encryption. It is easier to have a shared private key for members, then messages are encrypted only once and are not huge plus if a new member joins they can just get a copy of that private key.

 

Sources!@!

no sources?

 

vvv

 

Shadowcrew didn't use Tor they used a VPN that was in the physical possession of one of their members, he got arrested and turned under cover to bust the others. None of the (very publicly known) child porn rings on Tor have ever been shut down. I have yet to hear of a single person using properly configured Tor (Java and Javascript disabled) get traced back, let alone traced back and busted. Most of the carders use shitty single hop proxies that use SSL for encryption, same for most of the hackers. Of course those can be traced back. Tor can withstand a lot more scrutiny than other proxies and VPNs can, it isn't perfect but it adds a ton of security.

FBI can't decrypt AES or Serpent encryption. NSA possibly can but it would be extremely expensive and they would never do it for anything short of a national emergency, or spying on foreign military. And it is still a big "maybe", AES is what the military uses for top secret documents so I think that says a lot about how strong it is.

Tor can be traced back but it would be very expensive, it would cost tens of thousands of dollars to trace someone back over the Tor network. If they are using Wifi + tor and spoofing their mac address, there is next to zero chance of them being traced back.

Sure they can crack hotmail. And hushmail. They can't crack GPG encrypted messages with a 4,096 RSA/Elgamal key with a strong passphrase and a private key encrypted with AES-256 though. FBI and DEA can't anyways, NSA MIGHT (and it is a BIG might) be able to do so, but it would be very expensive for them to do and they are absolutely not going to do it unless it is a national emergency.

Paypal is a HORRIBLE method to pay for drugs. Western union is ok if you use a fake ID to send and receive but it still isn't that good. The best bet is to buy Liberty Reserve to a fake name (which is based in Panama, a country with laws that actually say it is ILLEGAL to cooperate with government agencies other than Panama and which is essentially the new Switzerland as far as money is concerned) with western union + a fake ID and then transfer it to a vendors account using Tor + Wifi, then for the vendor their best bet is to use several different exit nodes + Wifi and bounce the money around through four or five different accounts before having it cashed out to Western Union and picking it up with either question/answer or a fake ID, or paying some else to pick it up with a fake ID at western union and mail it to a PO box they bought with a fake ID and pick it up after letting it sit for a week or two.

Controlled deliveries are common knowledge, that is why you should have products sent to a private mail box obtained with a fake ID and let them sit for a few weeks before picking them up at some odd hour. 24/7 surveillance of boxes gets really really expensive really fast and it just isn't worth it for them to spend more money busting you than the value of your drugs are. If you don't have a real identity tied to the box they can't do shit about it.

Chances of being busted getting a gram of a research chemical are low. Chances of being busted importing things like pounds of weed or kilos of ketamine are high if they get intercepted and you take no security precautions.

I don't think just using Tor will make you immune. But you seem to think since Tor is not a magic shield there is no point to use it, and you are wrong. Tor makes tracing you back over the internet go from as difficult as 30 minutes and a warrant to tens of thousands of dollars of forensics equipment (plus the time and therefor expensive salary of the limited amount of people trained to use said forensic equipment) and at least three warrants with a high chance of the warrants needing to be served in three different countries around the world. Pretty much

not using tor: Quick and easy to trace you back

Using Tor: Possible to trace you back, but very expensive and time consuming

 

I think most people on the web buy a gram or so of some semi-legal substance that LE really doesn’t want to waste the time and money to go after.

But if you want to super encrypt your hard drive to another state to use an internet connection have the stuff sent to another country and sit in a box for 3 months and pick it up with a mask and gloves then roll your getaway car off a cliff.

.. I could care less,

I am just trying to put out a few common sense safety tips with a few random bits of collective info. take it you like.

People should do their own research and weigh the risks..

 

Your safety tips seem to consist of don't bother trying to be safe because big brother is watching ;-P

Here is a nice (uncompleted but still very big and fairly complete) (slightly outdated) guide on mailing drugs and using the internet to arrange things. It is fully referenced and indexed with all sources cited.

http://www.filefactory.com/file/a01f928/n/guide_zip

 

Mostly don’t attract attention to yourself if you are doing something illegal.
Like wear a ski mask to the coffee shop in the middle of summer.

 

I can honestly say if you need to encrypt something DO IT YOURSELF! Dont use a mmajor program. Create one!

Encrypt a File using Ruby

How often have you heard about people selling their computers on an auction site, only to later discover that their sensitive information had been exposed on the Internet? And what about corporate espionage, or all those missing government laptops? If you talk to security experts, one of the first recommendations they make is to encrypt sensitive information. There are many encryption algorithms from which to choose, all with varying levels of strength. In this example, I will be using Blowfish, a very fast, symmetric block cipher.

encrypt.rb

Code:

require 'crypt/blowfish' 

 unless ARGV[0] 
     puts "Usage: ruby encrypt.rb <filename.ext>" 
     puts "Example: ruby encrypt.rb secret.stuff" 
     exit 
 end 

 #take in the file name to encrypt as an argument 
 filename = ARGV[0].chomp 
 puts filename 
 c = "Encrypted_#{filename}" 
 if File.exists?(c) 
     puts "File already exists." 
     exit 
 end 
 print 'Enter your encryption key (1-56 bytes): ' 
 kee = gets.chomp 
 begin 
     blowfish = Crypt::Blowfish.new(kee) 
     blowfish.encrypt_file(filename.to_str, c) 
     puts 'Encryption SUCCESS!' 
 rescue Exception => e 
     puts "An error occurred during encryption: \n #{e}" 
 end

Pretty simple!

Running the Code
You must have the Ruby gem crypt installed on your system—use the command gem install crypt at the console to install the crypt library. This encryption script is accessed through a command prompt. To run, type:
ruby encryption.rb /path/of/file/to/encrypt

You will be prompted for a password:
Enter your encryption key (1-56 characters):

Warning: Remember your password, or you won't be able to decrypt your file!

Now press enter and, if the encryption was successful, you will see this message:
Encryption SUCCESS!

Look in the folder where this script resides; you will see the new, encrypted file, named Encrypted_<filename>.

How It Works

In the first line, I include the library used for encryption: crypt/blowfish . Note that you could change this to use another algorithm, such as Rijndael or GOST. Line starts the creation of our encrypted file. Creating files in Ruby is very simple. As you can see, I used a shortcut to name the file by including the variable (filename) in line with my string, Encrypted_#{filename}. I enjoy having the option of including variables in line with a text string, so you will see I use them throughout this book.

Next, we check to see if the encrypted filename already exists. We don't want the script overwriting files arbitrarily—data gets lost very easily that way. If there is no conflict, the script continues on . Now that the script knows the encrypted file hasn't already been created, an encryption key, or password, needs to be provided by the user. The script asks for a key that is between 1 and 56 characters . Once all the ncessary information has been collected, the script starts a begin/rescue error-handling block . The last and most important piece of the script is the actual encryption of the data. A new encryption object is created with the encryption key passed as an argument . Then the file is passed to the encrypt_file method, and poof—the file is encrypted . If any errors were encountered during the encryption phase, the rescue block is there to catch them and exit the script gracefully, reporting the specific error.


And as for then Decrypting it,

Decrypt a File

This code is structured much like the encryption algorithm, so I will focus on the differences between the two. I am using the same algorithm for decryption as used during encryption. As mentioned earlier, you can use any number of encryption algorithms—just be sure to use the corresponding decryption algorithm. Don't forget your password, or else you will have to write your own brute force script if you ever want to see your data again!

decrypt.rb
require 'crypt/blowfish'

Code:

 unless ARGV[0] 
     puts "Usage: ruby decrypt.rb <Encrypted_filename.ext>" 
     puts "Example: ruby decrypt.rb Encrypted_secret.stuff" 
       exit 
 end 

 filename = ARGV[0].chomp 
 puts "Decrypting #{filename}." 
 p = "Decrypted_#{filename}" 
 if File.exists?(p) 
     puts "File already exists." 
     exit 
 end 
 print 'Enter your encryption key: ' 
 kee = gets.chomp 

 begin 
     blowfish = Crypt::Blowfish.new(kee) 
     blowfish.decrypt_file(filename.to_str, p) 
     puts 'Decryption SUCCESS!' 
 rescue Exception => e 
     puts "An error occurred during decryption: \n #{e}" 
 end

Running the Code

The code is simple to execute; just type the name of decryption script followed by the file you wish to decrypt:
ruby decrypt.rb encrypted_filename.ext

The Ruby script will prompt you for the encryption key. Remember that you must have the key used to encrypt the file in order to decrypt it. If you don't, then there is no way to recover the file other than brute force, which can take much longer than you probably want to spend.

How It Works

The script starts by grabbing the filename from the command-line argument and initializing the variables that will be used. Whenever a file is created, you should always check to see if there is already a file with the same name. After the algorithms have been initialized, the script will ask for a key.

Up to this point in the script, everything looks as it did for the encryption script. Even if you type the wrong encryption key, the script will decrypt the file based on that incorrect key, with results as cryptic as they were before. If all goes well, you'll be able use the file that was previously encrypted.

The actual decryption happens using the decrypt method from the crypt library , which is just the reverse of the encryption.

If there are no errors or exceptions, the output will display Decryption SUCCESS! and the program will exit. If there is an issue, our begin/rescue block will catch the error and enter our rescue case. The rescue case displays an error message and notifies the user that the file has not yet been decrypted .

Any modifications you make to the encryption script must also be made to the decryption script. If you do a task in the encryption script and forget to undo it in the decryption script, your data will be history.

 

And because this deserves its own double post:
YOU CAN break AES using side channel attacks!

Admitadly, brute-forcing it isn't a option due to its complexity.

AND quantum computer allow all 3.4 x 10^38 guesses to be performed at once. So technically they could brute-force one with a good amount of time.
(When they exist)

 

Correction: You can weaken AES using side channel attacks. It has as of yet never been completely broken using side channel attacks outside of a laboratory with artificially created perfect conditions. In an applicable setting, side channel won't stand a chance of breaking AES. And Serpent is much more resistant to side channel attacks than AES, I personally suggest Serpent over AES but AES is just fine. If you are super worried about side channeling attacks do a cascade of twofish and serpent, twofish is very resistant to side channeling and algebraic attacks, where as serpent is more resistant to them than AES is and offers very conservative encryption standards.

Quantum computers are not real yet and some of the best minds in science don't think they are a real possibility. Quantum mechanics is real but a lot of stuff with the word quantum on it is just philosophy more than anything. Quantum computers might be a possibility in the future, they might not be, as far as the general public including the general world of academia goes, they are very far from realized. And if they are real in some secret NSA facility, you can bet your ass they are not going to blow their cover busting some internet drug users, they are going to keep their encryption cracking power secret for when a catastrophic earth changing emergency comes around and they really need to use it.

Also AES-256 has 2^256 possible keys, not sure where you got your numbers from. (115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possible keys, would take longer than time is left in the universe for all the computers on earth to exhaust the key space.)

 

As you said yourself, It has been done in prefect conditions, so I was correct.
But yes I do agree with you, the most they probably would be able to do is weaken it.

And I agree with you largely in this thread, however I felt it should be brought up.

That number came from some of my notes but I may have done something wrong, I'll go check. Thanks.

 

Yes it is a good point but I worry mostly that people will see that and decide there is no point in encryption because "AES can be broken" when a more accurate portrayal of the situation is "AES can be broken if the encryption and decryption is done on a special machine in a highly controlled laboratory and every single thing is set up to be as perfect as possible, such as it would never ever be outside of a laboratory setting."

I do think Serpent is the superior algorithm though and was shocked it lost to Rijndael for the AES title. (AES = Advanced Encryption Standard, a title currently held by the algorithm Rijndael, Serpent came in second overall despite kicking Rijndaels ass in the security department)

 

I agree Serpent is superior, and to anyone, and I do mean ANYONE who read my post. Listen to the above post.

Encription is good! There is a point!

 

What's the point? In your script you used some ruby encryption module, which is a mayor program/module in itself and can be just as flawed/backdoored as anything else. There are programs to do this already, open source programs too. Reviewing the source of one of them would much easier than creating your own if you are that paranoid.

Regarding the encrypted message board, I'm pretty sure that many have already been developed underground (probably not in drug-related circles though). I know of one which is pretty functionable. The methods used are mostly what binary shadow outlined with some modifications. It's planned to be released to the public in the near future, that will be the real test of it's design.

 

If you make your own encryption algorithm you probably fucked up unless you have a Ph. D in mathematics. Some of the worlds most brilliant mathematicians and cryptographers (plus the united states military, and millions of dollars in funding) resulted in the cryptography standards we have today. I doubt you can beat that.

AES-256 is used by military computers for top secrect documents. The government doesn't have some magic encryption no one knows about, cryptology is a public education field and the majority of insanely intelligent cryptologists and mathematicians don't work for the government, they work for prestigious universities and write articles about encryption in scientific journals. At the most the government has is Quantum Computers which can crack encryption much much faster. There are some advanced encryption techniques that can be used to attempt to withstand quantum computers (ELC and algorithms based on it I believe claims to withstand some non-trivial level of quantum computing power). But even if the government does have quantum computers (really unlikely) they are not gonna use them on us.

I still think serpents better tho.

 

I know of another one being developed right now. It uses client and server side components to create a secured and anonymous forum environment. All messages from one member to another are automatically encrypted with 4,096 bit asymmetrical keys, the public keys exchanged through a special sort of cryptological handshake with the server. The private keys are either inputted to the client side program, if they are compatible, or are generated by the client side program if so decided. Regardless the private keys stay private, not on the central server like all the stupid safe-mail and hushmail clones that are worthless from a security perspective do it.

The server itself is a Tor hidden service accessable only over the Tor network, the configuration of this is handled by the client and server, also there is an option to use an independently installed copy of tor and do it through SOCKS like most programs allow for. So this means, each member is 7 proxy nodes away from the central server at all times, the central server is 7 nodes from each member at all times, and each member is 15 nodes away from the other members at all time.

The actual posts of the database are encrypted for members of the group using strong symmetrical encryption systems, Serpent-256 being the primary choice. The password of the encrypted posts is on a client configuration file generated for each user by the administrator. Basically, when a post is made, it is automatically and transparently encrypted symmetrically with a keyfile shared by all members of the forum. This is all handled by the client, the user can't even see it.

The communications from and to the server are also encrypted with multiple layers of additional encryption thanks to the Tor network doing this by default, so we have multiple layers of multiple types of encryption involved at most points in the process.

The actual client side program is installed by an installer program that requires a USB and encrypts a shell file on the USB with very strong encryption (AES-512) and leaves just enough space to install a decryption program to the USB key as well as a U3 style instant launcher. The shell file has a hidden section accessed by a secondary password where the actual client software is installed, the second section is opened with another passphrase and is filled with user determined fake incriminating material, so if ever court ordered to a member could reveal a passphrase with out compromising the group. The installation program has three options: Encrypt USB with one file, Encrypt USB with two files, Encrypt USB with one file and client. That way the courts can't automatically say if you have this program you are a member on a group or you have two passphrases. People could make the program encrypt whatever they want and not have the client involved at all, so this gives great plausible deniability for a court room.

Authentication and login are handled by a handshake that involves the server generating a twenty character long random string and transmitting it to the client (as always over the tor network). The client then signs the string automatically and transparently with its private key and uploads it back to the server. The server authenticates the signature compared to a public key it has on record from the member (either input by the administrator or automatically uploaded form the client during the first connection period when a presence is established). Anyways, the server authenticates the signature and then it validates the string to make sure the signed string is the same as the string it generated. It can use KeyID of the signature to automatically log the user in, no password will be required for this system and user name will be that of the public key. Authentication will be done every single time a user performs an action that calls for data to be sent from or too the server. This protects sessions and also secures the system.

Virtual keypads with rotating characters on them will be made available on screen for whenever a passphrase needs to be input by the user (which is almost never, only when they launch the client from the encrypted shell, and when the handle private message decryption unless they select to use a keyfile for that but default will use a passphrase. All signatures and authentication keys and decryption of threads can be handled transparently by the client with keyfiles generated with strong hashing functions as the prng.

Oh, also, private messages are not stored on the server for longer than it takes for them to be downloaded, even though they are double encrypted even on the server. As soon as a client downloads a message it makes a whirlwind hash of it, then the has is uploaded to the server and if the hash matches the one stored on the server, the message is wiped from the server with a 3 pass DoD wipe with whilrpool prng.

 

I wasn't saying for security sake. I meant for fun...

 

All the differences in the design of the system I know of and what you outlined come from the fact that the former is aimed at a more hostile environment. By this I mean you probably don't trust other members, or the admins of the board and so on.

There have been a few ideas to solve the symmetric key shared by every member problem (well, it may or may not be seen as a problem) but none proved efficient enough. The current implementation allows user groups to be created with the different groups having different symmetric keys. It's possible to post in the same thread to several different groups and although it's a bit messy, it works quite well.

Also, the strong use of hashing to protect some information is a great idea IMO. Two examples come to mind. The board can function like the UD too, requiring you to know about a vendor to post/read other posts. The client only submits a hash of the vendor url/e-mail, so you can check if there's any discussion about a vendor and still not give it away (to the admins).
Another example is a source trading module, which currently exist only on a conceptional level. The participants exchange hashes of vendors with some descriptions they want to trade. It eliminates some problems of source trading but it's quite far from perfect. The only "perfect" way to trade source would (probably) be with the involvement a trusted third party. This idea looks promising but needs quite some work.