Slashdot Mirror
Intro to Encryption
An anonymous reader submitted a Techworld story which is a sort of encryption primer. The difference between codes & cyphers, and what all those acronyms like RSA and DES actually mean. This is good primer material for newbs, and a good refresher for fogeys.
...SSL and TLS, which includes an introductory that has a nice overview of encryption concepts and techniques.
The explanation of stream vs block ciphers is especially good, with nice examples showing how each technique works.
The Army reading list
If after reading the intro to encryption you are so inspired to try to crack one, I highly recommend this list:
http://www.elonka.com/UnsolvedCodes.html
Enjoy.
- tokengeekgrrl
What is the point of all these different encryption methods? No one has ever broken PGP. No one has ever broken GPG. No one has ever broken a well-protected OTP cipher (and they never will.) Why do they keep churning out new ones when the ones we have work?
**This begins my ever-changing sig
We need a -1 RTFA moderation option!
**This concludes my ever-changing sig
You're right.
There are other glaring inaccuracies, e.g.: An increasingly important use for asymmetric encryption is digital signing. A digital signature is the reverse of public key encryption.
This is sort-of true if you're talking about plain-vanilla RSA signatures (though even here, it's only about half-right). But in general, digital signatures have nothing to do with encryption. An encryption scheme does not always yield a useful signature scheme, nor vice-versa.
I'm developing a slow but very secure RSA cipher that treats your binary data as one large number. It will take the digits of this number in base m (where m is the modulus) and salt and encrypt each digit. This produces a data block that is encrypted using only one cipher. This eliminates the symmetric hole altogether, even though that hole is rather small. My new technique has value bacause the symmetric hole is still one of the biggest holes in the entire PGP system, next to implementation specific vulnerabilities.
Factoring specifically has nothing todo with anything that can break DSA. Improvements in NFS related algorithms could however... Also we still have ECC and a few lattice algos left [NTRU anyone?]
I wouldn't worry too much about it though. While I expect new algorithms [probably not even NFS based] to be invented at some point it probably won't be tommorow.
Tom
Someday, I'll have a real sig.
If you want to be absolutely definitely sure that no one can intercept your communication with someone then here's what you do.
1) Get 600MB of random noise data from listening for extra terrestrials from for instance SETI.
2) Burn two CD's, give one to your friend. Keep the other.
3) Encrypt your message by superimposing it on that noise at a given location.
4) send the message as well as the location with the random location that you started copying the noise from (from the CD).
This message can _not_ be deciphered if you make sure that you never reuse the same random noise. Even if you reuse it it is hard.
In addition, if you at some point expect that someone is on to you, just burn the two CD's.
At that point those messages can _never_ be deciphered. Even if you try for a billion years.
Simple.
Unbreakable.
The Internet is full. Go Away!!!
They didn't work well, which is why modern cryptography was born. As far as practical goes, practical is a function of necessity.
OTP has the significant shortcoming of key exchange. You have to have a method of distributing keys that will not be compromised. This is extremely hard to do.
If the book ever falls into the wrong hands, then you have to throw everyones book out, and start over. You have to have access to your agents that are inside. Are you just going to send them their new book to the Kremlin, postmark Blechley Park?
It can be done, it is inprenetrible, but has huge risks and shortcomings.
Over at SourceForge is a relatively new Project called Primary Cryption. Working code (for Win32/WINE) has already been released. The source code includes hundreds of lines of commentary about encryption, C programming tricks, and other stuff that you might find interesting. The logo may be of interest, too. Some discussions about it have been started at the HalfBakery and at sci.crypt.research Oh, and if you want to put some effort into figuring out how easy (or tough) it is to break the proposed encryption scheme, feel free! I'd like to know. Thanks!
During my army service, I was told about random number generating cards. Basic idea is very simple, use thermal noise in conductors/semiconductors as a starting point for number generation.
So if you need random numbers for encryption, try some googling, and you will find many variations on this theme - serial port based equpment; noise from sound card (low cost solution - all you need is software). There are also schemes for do-it-yourself equipment.
Unfortunately, you should be a bit reluctant to accept the idea that all these things work as advertised. Just for beginning, although thermal noise is white noise by default, it get filtered in system during the processing. Its spectrum will not be the same as it was on the origin. (I am not an expert, but I think that spectral characteristics of the signal is not a requrement for randomness, but this is still good example of possible flaw in implementation.)
If I would start using this, I would test this generators with some mathematical tools.
Also, there are encription cards. I was able to see one made by Soekris. It has hardware implementation of DES. DES is designed to be done in hardware - shifting and xoring is easy to implement in hardware. Soekris makes 486 and P5 low-consumption small sized boxes. With this card, you may make good and fast IPSec firewall that runs on 133MHz 486 (!). Unfortunately, I am not in touch with this equipment any more, but problem was that Linux driver was in alpha state (situation from 10 months ago). BSD drivers were in release state.
(One idea came to my dirty mind - how interesting this card might be for crackers?)
No sig today.
The primer seems a little overconfident about random ciphers
That's where I threw up my hands in disgust. I've never heard of a "random cipher" before. Did he mean one time pad? Those are provably unbreakable, assuming you have a good source of random numbers. Did he mean XOR the message from a cheap-ass PRNG? Unnacceptable. And why 4 bytes at a time? If it's just XOR, then 4 bytes at a time buys you nothing.
This article was written by someone who read someone else's articles, and understood about half of it.