Slashdot Mirror

Speaking as an Evil Genius with standards, and one who's read the Warhol Worm paper, I'd say any "decent" botnet doesn't take orders from just any old Bill, Fred, or Otto who wanders by waving an executable at it. A "decent" bot wouldn't run code handed to it unless the executable was cryptographically signed with a private key matching the public key it knows belongs to its One True Beloved Master.

So, all of your plans should work just fine... once you determine how to recover a GPG private key of the 4096-bit keypair needed to sign the RUNME code, using the public key taken from the sample bot.

HANGE. (Have A Nice Geologic Epoch.)

(Note: I have better projects to occupy my Evil Genius than botnets.)

Encrypt IM encrypt file sharing encrypt your email

Keep your data out of the databases. Use cash, ask marketers to remove your name from their lists. Use cash. Use cash. Use cash.

If you've got a "shoppers club" card with your name attached to it. Give it up. Cut it up. Get another one - without your real name and address.

Encrypt your IM traffic with others that are capable. Put SSL on your web server.

Adopt IPv6. Setup IPsec on IPv4/v6 connections. Use SSH (duh!). Get an anonymizer.com account. $30 bones for a year. You can get a 6-month free trial if you sign up as a member of the EFF. $25 bones. You get a sticker. Spend a little more and you get a hat or a T-shirt. Do it.

If you've got flash, watch this.

No need to contribute "useful" data to the databases, right?

Indeed -- and if I can win the lottery I will have no financial problems. These are nice things to fantasize about, but they're not wise to plan on when the odds are so fundamentally against them happening.

Remember, the Social Security Number in the US was originally supposed to be only for the purposes of administering Social Security. Now it is "mandatory" for a wide range of things including just having a place to live (e.g., as part of an application for an apartment, a mortgage, etc.). When I was growing up (and I'm only in my 30s so this isn't ancient history!), I didn't need an SSN until I was ready to get a job. We applied for them as part of a 9th grade class; none of my fellow students had one. Scant decades later, my children were required to have an SSN application submitted almost immediately upon birth.

Maybe it's time we blow of the dust of the (e.g.) pgp protocol, and try to find a way to make a official central directory in which we can be sure anybody is who he claims to be.

You mean, like a keyserver?

I wonder why PGP isn't more popular.

Probably because "average" people don't understand it and the principles of trust surrounding it. Nor do they want to learn, because, as Thomas Edison put it, "Five percent of the people think; ten percent of the people think they think; and the other eighty-five percent would rather die than think."

Could you please consider getting your GPG key signed by as many people as possible? Please? Perhaps anyone else on NANOG who knows you? Perhaps even by Verisign's Key?

(GPG/PGP Activism ...)

Could you please consider getting your GPG key signed by as many people as possible? Please? Perhaps anyone else on NANOG who knows you? Perhaps even by Verisign's Key?

(GPG/PGP Activism ...)

what's wrong with keyserver.net? I'm not sure if they still allow direct client access or if you have to do some manual clipboarding.

Also, there is no need for one centralized email key registry, just like there is no need for one centralized SSL depository. Just like you can have SSL certificates from different depositories, you can have different email key depositories. Authories could be built up much like the current SSL authorities, through being trusted in other areas involving sensitive information, or being known for having a strong stance on privacy. People could make money just like they do with SSL certs - charging a nominal fee for storage of their verified keys.

Do a little homework on this - it's not as tough as you make it out to be.

I have configured gpg according to to the webpage on the topic, but it just responds:

gpg: error sending to `search.keyserver.net': eof

I have e-mailed the webmaster, but no respons. I had a few responses from the gnupg-users mailing lists, but nobody knows anything to resolve the problem. I have even tried to talk HTTP to it. It seems like it just won't listen. Is the server broken?

Everything works fine with wwwkeys.pgp.net, though.

I have configured gpg according to to the webpage on the topic, but it just responds:

gpg: error sending to `search.keyserver.net': eof

I have e-mailed the webmaster, but no respons. I had a few responses from the gnupg-users mailing lists, but nobody knows anything to resolve the problem. I have even tried to talk HTTP to it. It seems like it just won't listen. Is the server broken?

Everything works fine with wwwkeys.pgp.net, though.

Have you considered getting a clue yourself?

Fingerprint = 86EB 2231 AF86 4B7E 46D2 5B10 6072 AE52 C2F8 37FD

Have a nice day of course ...

That HOWTO is good, but severely out of date. To quote Cha pte r 10 - Encrypting files and drives in Linux, BSD, and other Unices"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

Do you have files on your computer that you wouldn't want your spouse to read, or perhaps your main competitor. Chances are if you use your computer for work or general usage the answer is yes. Also what happens if you want to send a file to someone, or let them download it from you, but you only have access to a public site (like a free web hosting company). The answer is to encrypt the file, and fire it off. For UNIX you have several choices, PGP, and GnuPG, as well as Guardbot for web based file transfers. If you work with files that are sensitive (such as spreadsheets containing sensitive financial data) the constant hassle of encrypting and decrypting the file (as well as the fact a decrypted copy will be stored on the filesystem, leaving a window of opportunity for an attacker) can get tedious. If this is the case you will want to use software such as, BestCrypt (commercially licensed but free for Linux with source code), or PPDD (Private and Top Secret, GPL licensed) which are both very similar in execution and general usage.

Pretty Good Privacy is available as a command line driven program for most UNIX platforms, and there are a variety of front end GUI programs for it. I would not recommend using PGP on a UNIX platform since a completely OpenSource, and compatible replacement is now available, in the form of GnuPG.

GnuPG is a GPL licensed (a.k.a. completely free in every respect), written in Germany (a very pro-crypto and pro-privacy country). Since it is available in full source code chances are it has been ported to your UNIX platform (and if not try compiling it, it might work). You can download GnuPG as a compressed tarball of source code, and there are links to a number of source and binary packages for various UNIX platforms. Once installed GnuPG behaves very similarly to PGP. The first thing you'll probably want to do is generate a new keypair, simply use the command "gpg --gen-key", it will create a ".gnupg" directory in which to store your keys, option files and so on and exit, you then run it again and it will lead you through the key creation process. Choosing the defaults during key generation is a pretty safe bet, although you may want to use a 2048 bit keysize (realistically if someone manages to crack 1024 bit keys, chances are they can get at your 2048 bit key, however if they are only trying to brute force it a longer key is a good way to reduce the chances of that). For personal keys the expiry is typically set to "0" (that is to say they do not expire), however if these keys are for corporate use, or for really sensitive information it is a good idea to expire keys and rotate them (every month, year, decade, whatever your security policy dictates). The most important thing when generating a key (in my opinion) is the passphrase. This is a string of characters which should consist of letters (upper and lower case) numbers and punctuation marks, the longer the better (I'd say the bare minimum is 10 characters). This controls access to the private key, which is used to sign items (and if compromised means an attacker could easily impersonate you), and to decrypt data (meaning an attacker could access all your data). Keep your private key secure! If an attacker gains access to this key they only have to brute force the passphrase, which is typically a lot weaker then a random 1024 bit (or longer) key. Worse yet they may steal your passphrase, with a keyboard sniffer or similar attack, resulting in a compromise of your key. If the attacker does not have access to your private key they will be forced to guess it, which takes a brutally long time (on average however, there is a chance they may guess the key correctly on their first try).

Signing files is useful if you want to distribute a file to someone, and be able to prove that you sent it, and it was not tampered with. Internally GnuPG takes a hash sum (such as MD5 or SHA1) of the file (basically it reduces the file to a shorter, unique string of data) which it then encrypts with your private key, generating a signature. This signature can then be decrypted with your public key, resulting in possession of the hash sum of the file, simply take the hash sum of the file in question, and if the they match, then obviously the file is what it claims to be. This signature file can be a binary file, or converted into text (for example signing email, or distributing file signatures via email). To sign a file with gpg simply use :

which will create a detached signature of the file.

To verify the signature use "gpg --verify file.sig file". If all is well you should see something like:

If someone has fiddled with the file or signature you will see something like:

Encrypting files is also relatively simple, a person uses your public key to run the data through a one way algorithm which results in a seemingly random mishmash of data, you can then use your private key to recover what the original data was, thus decrypting it. To encrypt a file to someone you first need their public key, you can download it from their homepage (if they have it online of course), or you can go to a public key server, of which there are many:

http://pgp.ai.mit.edu/ - PGP key server
http://www.keyserver.net/ - OpenPGP key server

Once you have their key it is simply a matter of signing and encrypting the file (just encrypting the file is rare as there is no proof of who the data is from, unless you use some other method, like physically handing them a floppy disk with the encrypted file). The following is an example of me signing a file and encrypting it with my public key:

The user ID can either be the key ID (such as: 47D0D9A8), the email address associated with the key (seifried@securityportal.com)or the name (not recommended as these are not unique, there are many John Smith's). You will end up with a "file.gpg" that is binary, if you wish to send the file via email it is advisable to use the "-a" ("--armor") option which will result in "file.asc" and is ASCII text, so you can read it straight into an email, or print it out, mail it, and let them OCR and decrypt it at their end. To decrypt a file sent to you simply:

and it will display the file (hopefully a text file) to your screen, followed by the veracity of the signature (if you have the persons public key):

if you want to save the decrypted file simply use "--output filename" and it will dump the content to "filename". You can also use shell commands such as "|" or ">" to further mangle the output (this is useful if you have automated systems such as a reporting mechanism which sends encrypted emails to a central repository).

BestCrypt

BestCrypt is a disk encryption program available for Windows and Linux. The nice thing is you can create an encrypted container (a file that is then mounted as a filesystem), and use it in Windows or in Linux (as long as it resides on a partition accessible to both, so putting it on your Windows partition is fine since Linux reads almost all Windows partition types). BestCrypt consists of some kernel modules (so your kernel will need to support loadable kernel modules obviously, and it helps if you are using tools like depmod, modprobe and the kernel module loader), and a userspace utility called "bctool". This program is however officially in "beta testing" for Linux, and probably should not be used for critical data (if it is, make sure you have backups). After testing BestCrypt for Linux I am satisfied that even though the software is officially beta, it is probably stable enough for most users, however your mileage may vary, all sales final, and don't blame me for any lost data. The only real problem with BestCrypt is a severe lack of documentation, while there is a man page that explains basic options, there is not a single example of how to create and mount a container (I suspect the release will have documentation, their Windows version documentation is quite good, a half meg helpfile). You need to download the software first, available as a source tarball, and source rpm (very easy to install on an RPM based system). Simply download either one, I would recommend the source rpm if you can.

followed by a lot of text while it unpacks, compiles and assembles the source RPM and binary RPM. You should then have a:

Simply install the binary RPM with a:

If you do not have an RPM based system, or the source RPM doesn't work for you, compiling the source code directly from it's tarball should be possible. Simply download the file, unpack it to an appropriate place (such as /usr/local/src) and issue the commands:

And you should be up and running. The first step is to create a container (a file that is encrypted and mounted as a partition):

You can of course use the "gost" or "des" algorithms, I would not recommend them as gost is less tested then the "twofish" and "blowfish" algorithms that BestCrypt supports, and single des is to easy to brute force. The next step is to format the container, you'll probably want to use msdos if sharing with Windows (i.e. a dualboot Linux and Windows machine), or if just Linux then ext2 is a good bet. You can also specify the size, if you make it so small this can be a problem, but because it is a file and not a true partition you can easily create a new, larger file, move all the data to it and use it instead of the older smaller one.

Once the file is formatted you should be able to mount it:

As you can see it is mounted as a part of the filesystem, just like a floppy disk would be for example. Remember to control access to the directory hosting the encrypted files carefully, no matter how good the encryption, if you have it set world readable you won't have gained any security. Also remember that as a user, root owns the / and can take ownership of any file or directory and see what's in it. Alternatively if an attacker gains root access they can log your keystrokes (or terminal traffic) and gain your password (and access to your files). As always your security is only as good as the weakest link.

PPDD is similar to BestCrypt, but instead of creating a file, encrypting that and mounting it, it actually uses a partition which is encrypted and mounted using the PPDD driver, because of this it can do a few additional things BestCrypt can't. If you only want to encrypt a few directories then I advise compiling PPDD as a kernel module, but if you want to encrypt the entire file system (including what you boot from) you will need to compile PPDD directly into the kernel (although as of 1.0 it's not to hard). Unless you have a GPL only policy I would recommend using BestCrypt if you are new to this (it is easier to install and use, and you can buy support). PPDD does have one enormous advantage over BestCrypt however, you can encrypt all of the system, including the boot drive and swap partition, making it ideal for situations such as laptops with sensitive data and minimizing the risk (to zero if need be) of accidentally leaving sensitive data in an unencrypted location (such as the swap file, /tmp, and so on) so if you need a higher security level I would recommend PPDD over BestCrypt (simply because you can encrypt everything). Another advantage of PPDD is that is uses two passwords instead of just one for each encrypted filesystem, so you can give one administrator one password, and another administrator the other password, meaning no single person can gain access to the data. Unfortunately as of the writing of this chapter PPDD is not available for kernel 2.2.13 or 2.2.14, so you will have to run the older 2.2.12 kernel (which is the stock kernel on many distributions in any case).

Download PPDD, and unpack it in a suitable location, such as /usr/local/src/, there are several files you should read, most notable the README file, and once done install I would recommend reading the PPDDHow.txt file. Installation is rather simply with:

This will first test the kernel source to make sure it's the right version and so on, then it will test the patches, then apply the patches proper, and then create the devices needed (similar to what BestCrypt does). At this point you need to recompile your kernel, first make sure you go into the configuration (via make config or make menuconfig or make xconfig), and enable the PPDD driver (in the Block devices section). Then save the config file and recompile the kernel as your normally would. Once that is done you will have to install the new kernel (copy it to /boot typically, edit lilo.conf and rerun lilo). Once you have rebooted you will want to build the tools for PPDD and install them with:

At this point you should be ready to use it, however I would recommend running the tests with:

They take a while to run, but it will save frustration later on if something is broken. Using PPDD is relatively simple, there are a number of utilities for creating, managing, encrypting file systems, and so on. You will also want to set the permissions and ownership on the /dev/xxxx that contains your encrypted data so that only root has access to it, PPDD will complain otherwise

At this point you should have a directory called /crypt which is /dev/hda3 (although on df and the like it will show up as /dev/ppddx). I will cover how to encrypt you entire filesystem with PPDD, at a later date however (it is extensively documented though).

Another new possibility is Guardbot, which password protects www pages. Essentially there are two components, an applet that encrypts the data, using DES (56 bit keyspace), and an applet that will decrypt the data with the password you provide. The advantage of this over traditional server based methods of control (such as htaccess in Apache) is that the user manages it fully, and can protect each file individually without much setup. To fully take advantage of the keyspace available your password must contain upper and lower case letters, numbers (and punctuation marks, but this can confuse users) of around 10 letters, however since people tend to choose less then random passwords a longer password then this is advisable. This program would be useful for getting files to other people cheaply (simply sign up for some free web space, post the file up, and get the password to the other person securely).

It is no longer enough in some countries to encrypt your data to prevent access to it. Recently in Britain a law was created making it a criminal offence to refuse to give up encryption keys or plain text versions of encrypted data.

StegHide hides data in files such as sound and picture files where not all of the bits in a byte are used. Since the data is encrypted it will appear random, and proving that the data is actually there is difficult. The only downside is to store a one megabyte file you need a sound/picture file of several megabytes, which can be cumbersome (but hard drives and high speed access are becoming cheap so it's a moot point). You can get StegHide at: http://www.stego.com/.

Steganographic File System actually hides data on your harddrive, making it difficult to prove that it even exists. This can be very useful as the attacker first has to find the data, let alone break the strong encryption used to protect it. You can get StegFS from: http://ban.joh.cam.ac.uk/~adm36/StegFS/& lt;/a> .

OutGuess hides data in image files, meaning you can send files in a way that won't attract to much attention (and can't really be prooved either). You can get it from: http://www.outguess.org/.