Last night I wrote a simple encryption program. Basically it’s “Encryption for Dummies”. You can use it to encrypt text message such as email or even instant messages.
Here is the zip file: CryptLight_1_0_0_1.zip (225.56 KB)
Download it. Unzip it, read the ReadMe.htm file and you should know all you need to know about it. If it sounds like something you could use run Setup.exe and have fun.
As a test message use this with the passphrase of “Password” (without the quotes):
gmPtGYutvQCrqXMT++rFLwcN53qTuDpieDL/Z3svuIz4RnHNTCeJ+8aGC4Z2orZ9Zsen/rg7
8JG/Rm/cQ33D5bqSWqTXU4ctDCabZAKw2po=
Update: I forgot to mention, because of my exceedingly Microsoft centric view of the universe, this only works on Windows. I tested it on XP and 32 and 64-bit versions of Vista.
Update2: If you enter in corrupted cipher text and try to decrypt the program will crash. I have fixed it but haven’t released new version yet. I’ll wait for a few more days to get feedback and bug reports. Consider what you have as an Alpha release.
Excellent. I’m always in favor of good encryption being easier for everyone to use. I admit to knowing diddly about the state of user-level tools in Windoze, but I do recall comments from years back about how difficult it was to get PGP set up with your MUA. From what I’ve heard lately, for example, getting Enigmail working with Thunderbird is very easy now.
Of course, as Linux user, I know that some years ago, it wasn’t exactly easy there either. I mean, it was for me, because I didn’t mind recompiling my MUA with the appropriate options for linking in the Gnu Privacy Guard libraries. These days, the one I use — Sylpheed — is smart enough to use the libraries if they exist, and not fail on startup if they don’t.
Still, I’m guessing the general consensus among most users is that using good encryption is too hard. I can think of 4 people I know who are each quite intelligent, but for them, the computer is a mysterious thing, and they do well to just keep track of their e-mail and other simple things. And, honestly, most people I deal with don’t see good personal encryption as valuable. I suppose they think I’m too paranoid, but I of course think they aren’t paranoid enough. 🙂
I admit I also just like the cool secret decoder ring aspect of using encryption.
The other problem is getting people to use good passphrases. I have a few tricks I use when I need a strong passphrase, but I’ve had a few occasions to know the passwords chosen by others, even tech-savvy types, and it gives me little confidence that most end-user types would choose good passphrases.
Thanks Jed.
Yeah, passphrases are a weak link. And it scares one even more when you read about some of the tools used to find the weak ones. Dictionary attacks that only take a few minutes and that sort of thing.
If we ever meet face-to-face I’ll tell you about my devious plan on the encryption front. You might be interested in helping.
Plotters! Schemers! Anarchists, terrorists, and ne’er-do-wells! If you have done nothing wrong, you have nothing to hide!
Seriously, what’s the balance-point between keeping your conversations private and drawing unwarranted attention from the ever-snoopy feds? I’m not talking about the way things should be, just the way they are.
Actually, in re. a “balance point”, the best thing to do would be to encrypt all your electronic communication, so that nothing stands out from the rest. And the more people who do so, the better. Until encrypted communications becomes the norm, it will stand out. I haven’t any idea if there’s some threshold level or pattern which will trigger some sort of scrutiny. My guess, and it’s only a guess, would be that it would be combined with something else, perhaps traffic analysis, before it would attract attention.
Joe,
It would probably be a good idea to add a no-export clause to your license agreement? I don’t know if the law was amended to eliminate liability in your case, but it used to be the legal equivalent to selling munitions.
I think overseas traffic of encrypted messages will get immediate attention.
Domestic traffic probably depends on who the messages are to and from. Beyond that I don’t even have any basis for speculation.
TJH,
License agreement? What license agreement? 🙂
Beyond that the encrpytion algorithm is implemented in the Microsoft Common Language Runtime and distributed by Microsoft. I just put a simple user interface around it.
Joe,
We should chat about this at some point in the near future. I’ve been working on some devious plans concerning encryption myself. The fact is, certain basic protocols need to be reworked with encryption as an integral and transparent component of the protocol rather than an optional one. Until that happens and the resulting protocols are brought into general use, only some minimal fraction of users will be sufficiently competent and interested to use encryption.. which means those who make that choice will be viewed with extra suspicion, regardless of the classic “you send postcards, I use an envelope” argument.
Triggerfinger, maybe we can find a few minutes at Boomershoot.
TF, while I’m massively in favor of more people enjoying the benefits of encryption, I wonder about building it in at a basic protocol level. I admit, I’m no expert on either the std. IP stack, nor a mathematician. But I wonder about how you’d deal with a crack on whatever scheme it is that’s embedded into one of the layers. Sure, you could have pluggable cipher modules (etc.), but how would people react to having to fiddle with those? Well, as always, the devil is in the details. That said, SSL seems to work pretty well. Been a long time since I read anything about IPSec, but I recall some complaints about it, though not the details.
I suppose I ought to generate a new key pair.
/me mumbles about coming up with a good passphrase I can also remember.
Joe, would you be open to passing a few ideas around via encrypted e-mail? I’ll forewarn you that I’m pretty awful sometimes about e-mail (just ask my mom), though typically better when it’s geeky stuff.
Jed, sorry. That just wouldn’t work. You will immediately understand once I explain it. It’s not something that has a lot of practical value but it would be very interesting.
Can you make it to Louisville?
As an alternative I can probably make room for you at Boomershoot if that would make it realizable.
Or if you ever travel through the Seattle area that might work as well.
Joe, thanks for the offer, but unless something unexpected happens, I won’t have the money for any trips this year. If I get the CTH gig I’m currently interviewing for, and it turns perm, I should be in a position to take 1 or 2 trips next year (depending on how much I spend on guns :).
Joe, that’s pretty much the time and place I was thinking of.
Jed, the problem isn’t about technology per se so long as there is enough scrutiny to identify problems. The problem is making it not only easy to use, but the default choice. Currently it’s possible to exchange encrypted email using SMTP, for example, but that’s a very weak guarantee; you have to trust the keyservers or exchange keys by hand, the keyservers probably won’t scale to full-internet use; you have to trust your domain name servers to give you the right answers; and worst of all, you have to set it up yourself and choose to use it each time. (There are other flaws in the core email protocols that I won’t go into here — but think spam).
SSL and similar connection-level technologies won’t do it by themselves, though they may be part of the solution.
You can get fairly transparent (users don’t see any change) email encryption using SMTP over a secure channel, but that only protects the message between servers. At work, our email gateway is configured to request a secure channel (using TLS I think) for all outgoing email. This doesn’t help if the server on the other end does not have a certificate from a trusted CA though. It also doesn’t seem to provide for encrypting inbound traffic, although that may be a simple certificate problem on our end.
I’ve also played with message-level signing and encryption using certificates, but that has other issues (finding intended recipient’s public key, certificate verification, etc).
As for encrypting email being a “suspicious” activity, I just think of it as complying with those privacy and data protection acts on a personal level. I’d hate to have to sue myself for compromising any of my sensitive data.
Brian,
I’m aware of SMTP-TLS and SMTP-over-ssl. Part of the problem is that there is no signing authority issuing reliable signatures for that. You can confound an evesdropper on your network but you can’t do much about attacks on your DNS servers (see cache poisoning, for example) except for whatever short list of email servers you can procure known keys for ahead of time. If you don’t have the known key, a man in the middle attack will work.
If it were easy someone else would have already solved it. Instead we have many different pieces that you can use if you know how to put them together, and a bunch of places that sell secure email services when they really mean “trust us” email.
Encryption? A good thing. Closed source implementation–not so good due to no peer review of algorithm and implemetation. Better then nothing, which is what I currently use.
If you know how to solve some of the problems with the SMTP protocol, publish an RFC.
Chris,
Publishing an RFC will definitely get done when I’ve got the kinks worked out.