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.

Comments

intro to encryption

[JavaLord]

svefg cbfg!

Re:intro to encryption

[Anonymous Coward]

svefg cbfg!

V snvy vg :_(

Re:intro to encryption

[Anonymous Coward]

a b c d e f g h i j k l m n o p q r s t u v w x y z
n o p q r s t u v w x y z a b c d e f g h i j k l m

first post!

Re:intro to encryption

[pete-classic]

Try this.

-Peter

Re:intro to encryption

[Anonymous Coward]

YBY BZT JGS! LHB ZNQ3 GRU SHAAL!!!!}=3Qe}'}"}SS}#.!}8}=
]"}&}=20 ]} } } }&..}=3Qe}'}"}[AB PNEEVRE]

Re:intro to encryption

[virid]

i hope you didn't actually need to chart that out...

Re:intro to encryption

[Anonymous Coward]

ROT13 - you go!!
Thats the same encryption IExplorer uses!

Re:intro to encryption

[Anonymous Coward]

or the unix shell way: tr a-z n-za-l

Re:intro to encryption

[wximagery]

I thought about trying to decypher it, but the little voice in my head hinted that the orignator could be screwing with everyone by creating a totally bogus cypher.

fjeq nfit ems!

"The guy who wants to mass produce nukes doesn't scare. It's the guy who wants to buy just one."

Re:intro to encryption

[budly]

Isn't rot13 encryption the greatest?!

Re:intro to encryption

[justforaday]

Nope...Double, or better yet, quadruple rot13 are the greatest...

Re:intro to encryption

[Tribbin]

Darn swedish

Re:intro to encryption

[maxwell demon]

I actually prefer the following method: For the first 49 primes, do an rot-p encryption. As key, use the order of these encryptions. Given that there are 49! different keys (that's about 6*10^62), it's a rather secure encryption method.

Re:intro to encryption

[roxtar]

#!/usr/bin/perl
$input="svefg cbfg";
$input=~tr/n-za-m/a-z/;
print $input;

Re:intro to encryption

[MagikSlinger]

Cracking this:

1. Try the obvious. Since this is SLASHDOT and most of its users are USENET geeks, try the famous ROT13. Works. But that's boring.

2. Guess the message. Hmm, it was modded funny, and it's a first post. This is Slashdot, so maybe it's first post? Right number of letters. Since 'st' are common last letter, check the last 2 letters of the words: bingo!

3. Start with the obvious. A cesar cypher seems likely considering all the clues point to it. You'll quickly notice the a=n pattern which brings us back to ROT13.

I'm just an untalented dillitante. I was hoping the more experienced cyperpunks would have posted something educational by now. ;-)

Re:intro to encryption

[SirTalon42]

HA! IE has better encryption than that! Just like theres now TrippleDES, IE uses DoubleROT13!

Re:intro to encryption

[maxwell demon]

Actually you should use tr a-zA-Z n-zN-Za-mA-M

First, don't forget that there are uppercase letters as well (even if you personally don't use them), and second, you don't want to lose those m letters, do you?

Re:intro to encryption

[Black Perl]

I use ROT26, myself.

Re:intro to encryption

[over_exposed]

No... He's New Here.

Re:intro to encryption

[swillden]

Given that there are 49! different keys (that's about 6*10^62), it's a rather secure encryption method.

You, sir, owe me a keyboard. And perhaps some new sinus passages.

Re:intro to encryption

[swillden]

svefg cbfg!

Ptr mhh xtlr. Mkr mabl hgx.

For anyone who hasn't run into it, you should find a nearby *nix system and try the command "caesar". It implements ROT-n substitution, not just ROT-13 and, even better, if you give it some encoded text it tries to guess the value of 'n', based on simple letter frequency. On short phrases it does very well at guessing arbitrary rotation values.

Re:intro to encryption

[Anonymous Coward]

49! different keys (that's about 6*10^62)

I assume that you are kidding, but wanted to point out the eroneous math anyway. The math works out to be closer to 14! (8*10^9), which is about 26^7 (7 random letters).

The reason is, because rot-p works with p mod 26. The distribution of the first 49 primes mod 26 works out to only be 14 distinct numbers.

Re:intro to encryption

[simcop2387]

also considering the fact that it wouldn't matter what order you did it in

rot1 + rot1 = rot((1+1) mod 26) = rot2
rot10 + rot16 = rot((10+16) mod 26) = rot0

you only have one possibility it comes out to
rot((2+3+5+7+11+13+17+19+23) mod 26) = rot22

show me an order of the primes where (2+3+5+7+11+13+17+19+23) mod 26 is not 22, and i'll break it with rot4

Re:intro to encryption

[zobier]

How's the .sigsperiment going? It's pretty funny.

Re:intro to encryption

[Black Perl]

How's the .sigsperiment going? It's pretty funny.

Thanks. Actually it's been good for my karma. Some moderators dutifully comply--even on non-insightful humor bits. That's pretty funny.

Re:intro to encryption

[jachim69]

Quicker way:

a b c d e f g h i j k l m
z y x w v u t s r q p o n

Re:intro to encryption

[Anonymous Coward]

Oh dude, if I could only mod + up your post, I'd do it.

Re:intro to encryption

[Maniac]

Erm... no... actually rot13 is

a b c d e f g h i j k l m
n o p q r s t u v w x y z :)

Re:intro to encryption

[Anonymous Coward]

Uh, shouldn't that be tr a-zA-Z n-za-mN-ZA-M?

Inaccuracy in article?

[DarkHelmet]

About RSA: Current hardware means key lengths should be 1024 bits for complete security. The present generation of web browsers use 128-bit keys so cannot be considered secure against a determined and sufficiently well-resourced attack.

Certificates are 1024 or 2048 bit with SSL. On the other hand, once the key is sent and shared, a 128 bit symmetric form of encryption is used. The only thing RSA is used for is sending / receiving the symmetric encryption key, yes?

Correct me if I'm wrong.

Re:Inaccuracy in article?

[Anonymous Coward]

Correct me if I'm wrong.

No.

Re:Inaccuracy in article?

[cpeikert]

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.

Re:Inaccuracy in article?

[Ann Coulter]

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.

Re:Inaccuracy in article?

[Asgard]

I don't think the use of a symmetric system is considered a hole; the idea is that symmetric systems are strong keybit-for-keybit. As long as the symmetric and public key stregths are similiar there isn't a weakness one way or the other.

Re:Inaccuracy in article?

[wfberg]

About RSA: Current hardware means key lengths should be 1024 bits for complete security. The present generation of web browsers use 128-bit keys so cannot be considered secure against a determined and sufficiently well-resourced attack.

Certificates are 1024 or 2048 bit with SSL. On the other hand, once the key is sent and shared, a 128 bit symmetric form of encryption is used. The only thing RSA is used for is sending / receiving the symmetric encryption key, yes?

Kinda yes. The public key is used to encrypt the session key, which is used in turn to encrypt the payload using a symmetric algorithm for speed.

Certificates are a bit bigger than 1024 or 2048 bits. They contain the public key (consisting in the case of RSA, among other things, of the 1024/2048 bit modulus) the owner's identification (e.g. e-mail address, common name, url, ..), validity dates, and a digital signature from a certificate authority (in some cases they're only self-signed, in other cases, dosens of people may contribute to authenticating a public key's ownership information, as in PGP).

A certificate is just that; it's to certify that a certain public key belongs to a certain entity.

If you pay enough to microsoft/opera/etc., you can certify anybody you want and all internet explorer users will take it for granted, because no one checks certificates.

Re:Inaccuracy in article?

[evilviper]

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 don't understand your point here...

Digital signatures most definately have to do with encryption, otherwise they could be forged, trivially. Absolutely any public-key crypto-system should be able to be used as the main part of a digital signature system.

Perhaps I misunderstand what you are trying to say.

Re:Inaccuracy in article?

[XMyth]

How do PGP signatures work then?

My understanding was this...for the signature portion at least...

Sender/Signer:
Hash message -> encrypt with private key (TO public key implied..)

Recipient:
Unencrypt transmitted encrypted hash with public key -> hash original cleartext message -> compare

in that case the encryption would be a necessary step to the signature. Is my understanding of digital signatures (PGP at least) wrong or did I mis-interpet your post? Could you provide me with a link if so?

Or, if PGP signatures fall under "plain-vanilla RSA signatures" then what other types of signatures are we talking here?

Thanks

Re:Inaccuracy in article?

[mr. mulder]

You're correct - somewhat.

Many assymmetric encryption schemes only use public/private key pairs to establish a secure connection. Once a secure connection has been established, most schemes generate a private key that will be used for symmetric encryption.

The reasons for switching to symmetric are many, but primarily it is done for speed. Symetric encryption algorithms are very fast compared to assymetric. Also, symertic algorithms can easily be implemented in hardware, thus, speed boosts are even greater when switched to symetric algorithms.

This kind of answers your question, but there are still a few crazy zealots out there that insist upon the sole use of assymetric algorithms - it is more secure, but worlds slower.

Re:Inaccuracy in article?

[cpeikert]

The confusion stems from the fact that the RSA family is pretty good for both encryption and signatures, though it is used in a different way for the two applications.

One other standardized signature is DSA, which is based on the hardness of computing discrete logs. The DSA algorithm itself is not the inverse of any secure encryption scheme. (It's worth noting that there are some encryption schemes based on discrete log; they're just not the inverse of DSA.)

Re:Inaccuracy in article?

[scribblej]

Uh... isn't that exactly how RSA works already? RSA doesn't include anything to do with symmetric-key algorithms on it's own... you've got to add that on top if you want it.

Or was that supposed to be modded funny? I don't get it.

Re:Inaccuracy in article?

[Anonymous Coward]

Correct me if I'm right.

This is Slashdot, after all.

Re:Inaccuracy in article?

[Anonymous Coward]

Only an ass-symmetric scheme guarantees a secure connection using private parts.

Re:Inaccuracy in article?

[nwbvt]

A couple of guys already beat you to it (look at their initials if you don't know who they are).

The reason the symmetric key is added is because raw RSA is just plain too slow with long messages. As long as the symmetric key is secure enough, it makes up for the insignificant loss of security. The biggest hole is probably the potential for finding an easy way to factor those numbers you are using.

Re:Inaccuracy in article?

[ajs]

Ah... symmetric hole?! What symmetric hole?

The symmetric key cryptosystems used by almost all modern public-key systems to encrypt the bulk of the data stream (where public-key is only used to transfer an initial session key) tend to be far more demonstratably secure than most public key cryptosystems.

The only reason we use public key at all is for the ability to exchange keys over a public channel, otherwise they would not be terribly interesting.

Re:Inaccuracy in article?

[BlueMonk]

I made a program that can actually use RSA for encrypting a whole file/message (based on base 256, base 64 and base 10 conversions of RSA transformations on huge numbers). Is is kinda slow with larger key sizes, but not intolerable. And it allows quite large keys (larger than 1024 bit).

Re:Inaccuracy in article?

[capilot]

Actually, the article was one howler after another. I cringed all the way through it.

Re:Inaccuracy in article?

[Lord Dimwit Flathead]

The first part of that paragraph bugs me too:

Unfortunately, nothing in life is free, and so it is with asymmetric cryptosystems. Since d can be computed from e given p and q, and p and q are the factors of N, they must be chosen so large that N cannot be factorised in any reasonable time.

While this is accurate, it's the first and only mention of d, e, p, q and N. The author also never actually explains that RSA is built on the assumption that prime factorization is mathematically hard. It appears that he simply cut-and-pasted from another text without bothering to make sure that it fit with the article. I can only imagine the confusion of the poor newbies trying to make sense of this.

Re:Inaccuracy in article?

[swillden]

An encryption scheme does not always yield a useful signature scheme, nor vice-versa.

Well, not trivially, anyway. Rivest showed that given a signing algorithm you can use "chaffing and winnowing" to effectively encrypt and decrypt a data stream. I can't think of a way to use an encryption algorithm to do signing (not in the sense of a PK signature), but there may be one.

For every rule, there is an exception :-)

Yes, the preceding statement is a rule.

Re:Inaccuracy in article?

[cpeikert]

Well, not trivially, anyway. Rivest showed that given a signing algorithm you can use "chaffing and winnowing" to effectively encrypt and decrypt a data stream.

Yeah, but "chaffing and winnowing" doesn't result in a public-key cryptosystem; it's best used as a symmetric-key system.

Even using (public-key) signatures, C&W doesn't yield a public-key cryptosystem: the sender is the one with the secret key, and the receiver holds the public key. That's flip-flopped.

Furthermore, C&W has never been formally proven to yield a secure cryptosystem (and I doubt that such a proof even exists). The point of C&W is just that, in the symmetric-key setting at least, the line between "authentication" and "encryption" is a little blurry.

Re:Inaccuracy in article?

[Mr Z]

All a signature is is a one-way hash. If you want to verify the integrity of a message (not necessarily identify its author), you can do so by encrypting the message with a known key using cipher-block-chaining, and the last block doubles as a checksum for the whole message.

To verify identity with a symmetric cipher, you're back to needing a shared secret. In that case, substitute "known key" with "shared secret key".

--Joe

Re:Inaccuracy in article?

[Mr Z]

Or, more accurately, the asymmetric public key is used to encrypt/decrypt the "session key," which is the symmetric key. Typically, the session key's generated on the fly randomly. They don't get reused. The public key does.

That's why it was such a big deal when people found random number generator flaws in early SSL browsers. The session keys turned out to be rather predictable if you knew what time it was.

--Joe

Re:Inaccuracy in article?

[plover]

You can use a secret-key algorithm as a proof to the other holders of the key that you know the key by using it as a secure hash algorithm. But you're right, you can't use a private key algorithm as publicly-verifiable proof of a signature.

For example: Alice can encrypt each block of data in the document with her secret key, and XOR them all together. She then sends Bob the value along with the document.

Bob can take the document and perform the same hash function using his secret key. If they match, Bob knows the signature on the document came from someone else who knows the secret key.

This probably doesn't meet your requirement as a signature in that a third party can't tell Bob's signature from Alice's. They can send a challenge to both Alice and Bob asking them to sign the document after appending a random nonce and validating that the received signatures match. But as long as Bob and Alice can be sure that the document was signed by an authorized key holder, they may not care which keyholder performed the signature. It's application dependent.

Of course the third party can't be more involved anyway since in order to validate a signature they would have to know the key. So, its real only use is as a tamper-proof seal that Alice and Bob can use between themselves, perhaps a convoluted proof that an archived document hasn't been tampered with.

Re:Inaccuracy in article?

[plover]

Well, there once was a hole or two in PGP that exploited the insecurity of the session key also. As I recall (mind you, I have a pretty poor recollector) the session key was stored in the clear, and the session key generator was a PRNG that could be "wound forward" given a previous session key. Both of those allowed an attacker a way to use a "known" value of the session key to run the PRNG forward and backward, trying all possible session keys on the message to see if they worked.

This was cured by encrypting the session key file and I think they used some kind of a stronger PRNG to create new session keys every time.

Re:Inaccuracy in article?

[1u3hr]

Another inaccuracy: TFA says the German Enigma code was broken before WWII. Well, it was understood before the war, the Poles had actual Enigma machines and knew how they worked, but it still wasn't easy -- you needed to find the key being used for each message. A lot of this was down to finding or stealing codebooks. Of course the geeks at Bletchley Park then needed to decode the messages, and when keys weren't available, try to deduce them by various means, such as noticing that a certain station always began their daily message with a weather report, etc, and reverse-engineering the key. It's been said, and I'm no authority, that if the Germans had followed good coding discipline that their codes could never have been cracked in any useful time (it's rather pointless to decode military movements weeks after the event).

Re:Inaccuracy in article?

[Anonymous Coward]

Talking of asymmetric and symmetric key sizes, there have been many discussions on the theoretical cracking of (1024 bits) RSA.
See http://www.interesting-people.org/archives/interes ting-people/200204/msg00109.html

(Also from this link)

NIST says: "For data that needs to be protected longer [than 2015], the key size should be at least 2048 bits." (Otherwise they recommend that the RSA keysize be at least 1024 bits)

RSA also says: "..high-value organization [RSA] keys should be at least 2048 bits"

So you would think anyone who knows about security would want to know the asymmetric key size as well as the symmetric key size of the secure web site they're visiting.

Not so. In Mozilla/Firefox you can see at a glance the symmetric key size sure, but to find out the asymmetric key size you have to find the actual key and calculate it yourself. In Mozilla you can reject ciphers based on symmetric encryption method and hash method but not whether they have low asymmetric (RSA) keys. It is theoretically possible for a "secure" website to use an obscenely low RSA key, let's say 72 bits but use a 256 bit AES symmetric cipher. Mozilla/Firefox will most likely proudly say that the site uses "high grade" security anyway!

You would think this would be a priority for Mozilla developers, right? Wrong.

This has been in Bugzilla for years, with numerous duplicates yet no-one is working on it.

See: http://bugzilla.mozilla.org/show_bug.cgi?id=78837
Also see: http://www.dslreports.com/forum/remark,11293626~mo de=flat

Re:Inaccuracy in article?

[Mr Z]

Yes, many PRNGs can be wound forward/backward with some effort. That's where cryptographically strong hashes come in handy.

Linear Congruential and Linear Feedback Shift Register types I believe are particularly easy to attack this way. Lagged Fibonacci generators are also pretty bad.

Lagged Fibonacci generators are just LFSR's on steroids, if you look closely. The LSB is an LFSR, and the upper bits are LFSRs perturbed by the carries from the lower-order bits. Lagged Fibonacci generators are nice for some purposes, but I wouldn't use them for session keys. I use them for regression testing computational kernels against random test vectors, as they have exceptionally high periods. See Knuth, Vol 3.

I don't know what sort PGP used, but if PGP used one of those, tsk tsk.

Nowadays, programs should use a true entropy source (such as /dev/random) when it's available.

--Joe

Much better than that article

[yahyamf]

I would strongly recommend the Code Book by Simon Singh over that short article. It takes the reader from the Ceaser cipher all the way to quantum codes and is a very enjoyable read. The Codebreakers by David Kahn is also an excellent though somewhat lengthier volume

Re:Much better than that article

[Antony.S]

Heh, I'm going to a lecture of his in two weeks (on the offchance anyone here is, soton uni), not read any of his work yet but am planning on reading the code book before I go.

Re:Much better than that article

[ElectroKiwiMonkey]

The examples throughout Neal Stephenson's "Cryptonomicon" are pretty handy too. At one point Dr. Waterhouse has to put the chain back on his bicycle, and from there we get into an example of (as I recall) how the Enigma worked on a basic level. Bits and pieces on public/private-key encryption and EM snooping are just some of the other interesting sidetrips the author takes.

Re:Much better than that article

[Gigs]

I second that and also recommend In Code which brings you up to speed with the mathmatics behind cryptography in an excellent and easy to understand manner.

Re:Much better than that article

[kalidasa]

I believe that's Turing's bicycle that has the chain that keeps falling off if the wrong link coincides with the wrong spoke.

Re:Much better than that article

[plover]

Except the average manager won't be able to stay awake for much longer than a one page article. If the author of the article had actually had known what he was talking about and put in some actual facts instead of that completely erroneous paragraph about 128-bit vs 1024-bit (in which he completely demonstrated his lack of understanding) it might have been a useful executive primer on encryption.

As it is, I'm harming lots of electrons here discussing a valueless document.

Oh, and you're right about those books being excellent. But you should really warn people that The Codebreakers is about 1200 pages of excellence, and not exactly a bedtime tale.

Difference betwen Codes and Cyphers?

[NardofDoom]

That's easy. Code is what I stare at all day, while Cypher is the jerk who betrayed Neo in The Matrix. Duh.

Re:Difference betwen Codes and Cyphers?

[sn0wflake]

Oh my, that is such a predictable geeky statement that it isn't even funny. What happened to Slashdot?

Re:Difference betwen Codes and Cyphers?

[Anonymous Coward]

It became predictably geeky. ;-)

Re:Difference betwen Codes and Cyphers?

[Anonymous Coward]

That's easy. Code is what I stare at all day, while Cypher is the jerk who betrayed Neo in The Matrix. Duh.

But after staring at it long enough, you don't even see the code... just redhead, blonde, brunette...

Garbage

[Anonymous Coward]

This primer is garbage.

Re:Garbage

[maxwell demon]

No, it just looks like garbage, in reality it's an encrypted message.

Re:Garbage

[Anonymous Coward]

"This primer is garbage"
"No, it just looks like garbage, in reality it's an encrypted message"

Actually, you're both right.
It's garbage, encypted with ROT-26

Re:Garbage

[Anonymous Coward]

Someone should mod this up. People have a hard enough time understanding cryptography without all of the people out there spreading misinformation on the subject.

640 bits should be enough for anybody

[stecoop]

Rest assured that unless some one finds a mathematical back door that the algorithms approaching 1024bits will not be the weakest link in the security of your data (at least with hardware today). Just have a look at the key space in Distributed's RC5-72 vs. RC5-64. The key space for RC5-72 is astronomically higher than RC5-64.

Usually, the weakest link will be the user using short keys or the user using the same password on a weaker system.

Re:640 bits should be enough for anybody

[Anonymous Coward]

You brainiacs are all thinking too much.
Bits ... bytes ... rams... roms... I *EAT* that shit for breakfast.

In the military we solve this encryption issue clean and simple:
Hunt down that Eve person, send in the SWAT team and kill the bitch.

Re:640 bits should be enough for anybody

[Ignignot]

the weakest link will be the user using short keys or the user using the same password on a weaker system

That's why all of my passwords are a complete work of Shakespeare. Root is King Lear, my insecurest password (for aim, etc) is MacBeth, and my porn passwords are Romeo and Juliet! It does take some time to enter them though :-(

Re:640 bits should be enough for anybody

[Anonymous Coward]

a) "256 times more" is hardly what I'd call astronomically higher.
b) You are aware that symmetric encryption != asymmetric encryption, right? RIGHT?

Re:640 bits should be enough for anybody

[Anonymous Coward]

Bits ... bytes ... rams... roms... I *EAT* that shit for breakfast.

Didn't your mom tell you that eating chips all the day isn't healthy?

Re:640 bits should be enough for anybody

[Tribbin]

"Usually, the weakest link will be the user using short keys or the user using the same password on a weaker system."

I use a different password for my windows and linux systems. I never store secret information on a windows computer. I never share secret information with a windows computer. I never use network passwords from a windows computer.

... and I losslessly rip my CD's with 'extra paranoia' enabled.

Re:640 bits should be enough for anybody

[Anonymous Coward]

256 roughly turns days into years.

Re:640 bits should be enough for anybody

[Anonymous Coward]

..or a single computer into a small cluster.

Re:640 bits should be enough for anybody

[lukewarmfusion]

"...and my porn passwords are Romeo and Juliet!"

Well my porn passwords are Juliet and Juliet. It's a lesser known work, to be sure, but it's certainly steamier.

Re:640 bits should be enough for anybody

[tsg]

Well my porn passwords are Juliet and Juliet. It's a lesser known work, to be sure, but it's certainly steamier.

But much weaker since the dialog is little more than "oooh, yeah, right there baby" over and over.

Re:640 bits should be enough for anybody

[Anonymous Coward]

Don't forget that algorithms like RC5 can only be cracked in the true brute force way which is exponential in time. On the other hand, algorithms like RSA have subexponential (faster than exponential) algorithms for cracking them, which means that a similar increase in RC5 and RSA key lengths doesn't multiply the time of cracking by the same factor for the two searches.

In other words, adding a big to your RC5 key doubles the search space of the brute force necessary to crack it, while a bit increased on your RSA key less than doubles it.

I read this book, this is what I thought

[Shut the fuck up!]

d6a6bc0db10694a2d90e3a69648f3a03 8a89706b1ce31bc803bfde8cee6587db 0f4b65803f78b51e8946d4506ae62473 b99b64cc909c4efcb609ad83fba84a55 719ffbccd1f60fabb76192606929585c

Intro to Colour Contrast

[Anonymous Coward]

http://shit.slashdot.org/article.pl?sid=04/11/15/1 935233

Handbook

[Ann Coulter]

The Handbook of Applied Cryptography: http://www.cacr.math.uwaterloo.ca/hac/ is a very detailed guide to some cryptographic algorithms and theories. This is not for newbies at all. For those wanting to implement a particular cipher, this book is the place to refer to. On top of everything, it is free.

Re:Handbook

[melandy]

Cryptography - A Very Short Introduction is an good book to introduce concepts of crypto. It's not a detailed manual about how any specific ciphers work, just an introduction to concepts.

Re:Handbook

[wfberg]

I'd recommend applied crptography by Bruce Schneier instead.

Not only does it cover the same ground, it also goes into detail a bit more about real tricky business; protocols (where most mistakes are made these days, since nearly everybody uses off-the-shelf algorithms like AES, DSA, RSA and ElGamal). This guy knows how to write, and succeeds in warning you of potential pitfalls in a humorous manner. Also, he knows his stuff; he submitted one of the AES candidates, Blowfish.

Bruce also publishes the most excellent Crypto-Gram newsletter.

Beware of not heeding Bruce's stern words of warning. You may end up in the doghouse! The humiliation! The shame upon your house!

Re:Handbook

[Anonymous Coward]

Nooooo why did you do that. Our uwaterloo connections are already saturated enough as is.

Re:Handbook

[chialea]

Be careful about using anything out of that book (or any, really, but specifically that one), as it has some rather intersting known bugs. It's an entertaining read, and good for background.

(And thanks for the comment about protocols; I work mainly on privacy-preserving protocols that deal with large bodies of data. The notions of what constitute security are rather strict, because very subtle corrolations and bugs can be a real problem.)

Lea

Re:Handbook

[swillden]

I'd recommend applied crptography by Bruce Schneier instead.

Seconded.

But keep in mind Schneier's opening statement in his next book, "Secrets and Lies", which says that "Applied Cryptography" has probably led to the creation of more bad security than any other single text. Not because the book is bad (it contains errors, but they're fairly minor) but because the book makes you think you're an expert. After plowing through some 600 pages of dense material, you *have* to be an expert, right? Unfortunately, no, after 600 pages you're a layman with a solid overview of the topic.

Re:Handbook

[Anonymous Coward]

The books have different target audiences and don't really cover the same ground. Have you read both?

Re:Handbook

[bartc]

Also, he knows his stuff; he submitted one of the AES candidates, Blowfish.

I guess you meant to say twofish. </nitpicking

Re:Handbook

[5E-0W2]

Hardly, AC is just a "these are the algorithms" book, HAC actually goes into the details of how and why things work. If you read one, read HAC thoguh by all means reading both isn't a waste of time.

Re:Handbook

[plover]

Actually, Practical Cryptography is probably more useful to most people. In that book, Bruce provides real-world examples of security needs and then details how the protocols should be implemented so as to preserve that security. He leaves the math alone, and discusses the protocols and data instead.

He wrote it after realizing how poorly people had misunderstood his warnings in Applied Cryptography (as documented in Secrets and Lies.) I thought his warnings were plain enough, but apparently too many people just plopped in some encryption because they "needed" some, and Blowfish was printed right there in the appendix.

Re:Handbook

[flynt]

What? These two hardly 'cover the same ground'. AC doesn't delve into 'math background' until something like Chapter 11, and then you only get one chapter. HAC assumes you are very comfortable with math texts from the get-go. HAC is more like a textbook than AP, which is more of just a general survey. I'd say on the whole, HAC is a much more 'serious' book, although even HAC only scratches the surface of the 'real' math you need to know to be considered a real cryptographer. No one who simply reads this web page or AP could remotely be considered an 'expert' in crypto matters.

ROT13

[echocharlie]

Nyy V'ir rire arrqrq jnf tbbq byq EBG13. :)

Re:ROT13

[General Wesc]

Sometimes that's not good enough. In such instances, I always rot-13 it two times for twice the security.

Re:ROT13

[izomiac]

2 rounds? That's weak. I ALWAYS use 4096 rounds of ROT13 encryption when sending a message.

Re:ROT13

[capilot]

Nyy V'ir rire arrqrq jnf tbbq byq EBG13 Scary: I've seen enough ROT13 in my days, that I can now read it by eye.

Eric Rescorla has written a fine book...

[tcopeland]

...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.

Re:Eric Rescorla has written a fine book...

[tcopeland]

I should add that the book was published in 2001, so it's not exactly cutting edge. But most of the info still applies...

Comprehensive list of unsolved codes and ciphers

[tokengeekgrrl]

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

I realized something while reading the article...

[zerguy]

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 is good primer material for newbs

[JohnGrahamCumming]

That's some clever way of saying "crap", right? This article is horrible, and if I was an encryption newbie all I'd be able to do after reading this article is spout acronyms.

Here's part of what the article says about RSA:

"Unfortunately, nothing in life is free, and so it is with asymmetric cryptosystems. Since d can be computed from e given p and q, and p and q are the factors of N, they must be chosen so large that N cannot be factorised in any reasonable time"

THE ARTICLE NEVER STATES WHAT d, p, q, e OR N ARE. Sorry for the shouting but this piece o'crap is worthy of a /. front page?

John.

Re:This is good primer material for newbs

[yahyamf]

I agree completely.. The only good thing is that even a moronic post can generate some intelligent comments and pointers to better material :)

Re:This is good primer material for newbs

[Anonymous Coward]

"This article is horrible, and if I was an encryption newbie all I'd be able to do after reading this article is spout acronyms."

If you find encryption newbies, point them to the PGP user guide -- one of the best intros to encryption.

Re:This is good primer material for newbs

[Lehk228]

lets see, it's not all hat hard to figure out. d is the decrypted value, e is the encrypted value, p and q are the encryption keys.

MIRROR

[Anonymous Coward]

Here is the coralized link (coral cache):

coral cache link to article

Safe encryption

[darkstream]

When I want to email with a new friend using PGP encryption, I send him my key one character at a time via snail mail using newspaper clippings. The only time this becomes a problem is when the post office laps itself and delivers more than one letter a day, or gets an earlier letter there later than a later letter, but it's the only way to be sure the key never falls into enemy hands. Of course, I don't get to email many people these days...

Re:Safe encryption

[Anonymous Coward]

This wouldn't be a problem if you included the date from the newspaper clippings.

Or you could send him a large chunk of pseudo keys, appropriately differentiated, and then tell him which parts to use from which keys over the phone, or in subsequent letters.

Of course, your snail mail technique relies on the fact that noone cares about your communications enough to want to intercept the letters and gather your key in exactly the same way.

Then again, I thought PGP was based upon having a private and public key. You retain and do not disseminate the private key, and can freely publish the public key.

Get back to work... nothing to see here

[brsmith4]

Let's say you are 8 years old and you know next to nothing about computing in general and the word 'encryption' piqued your interest. It is at this point that I would guide you to this so-called "primer". WTF do the editors do all day? You submit a well-written story with lots of information attached and you get rejected. You submit an 8 year old's intro to cryptography (i.e. "How to play Celebrity Cypher in your newspaper") and it makes front page. I hope those guys aren't paid to edit.

Re:Get back to work... nothing to see here

[Anonymous Coward]

I hope those guys aren't paid to edit.

With all of the spelling errors, duplicates, and (oftentimes) incorrect speculation, it's pretty clear that they're not.

You must be ne-- *whack*

Applied Cryptography

[Meostro]

Bruce Schneier's Applied Cryptography is another excellent resource for all you crypto-geeks out there. It goes from the basics (including the substitution cipher presented in the article) through basic crypto (ENIGMA, DES) all the way up through state-of-the-art (don't think AES was in my 1st ed., but I believe it's in there now). He talks about everything from the theoretical to the practical, hash collisions to rubber-hose cryptography.

It comes with source too! You know you love source....

Re:Applied Cryptography

[NeoSkandranon]

rubber hose cryptography? is that like where you have to break the crypto by applying a rubber hose to someone in creative ways?

Re:Applied Cryptography

[dtfinch]

Great book.

Re:Applied Cryptography

[Meostro]

Precisely. Wiki to the rescue.

Re:Applied Cryptography

[Tumbleweed]

Yes, you use the "Sweat Hog Method," and keep the keys up your nose, where they are only reachable via a rubber hose. Very secure.

Really - who's going to want to even _try_ to get those keys? *cringe*

Re:Applied Cryptography

[iabervon]

Both editions of Applied Cryptography came out before AES. I remember reading the 2nd edition and then hearing about Twofish, and recognizing the name.

Re:Applied Cryptography

[SuiteSisterMary]

Think of it as encrypting something such that if you give out one password, you get your top secret data, and if you give out a different password, you get something else; say, fake top secret data. Then, making that encryption scheme work such that you are utterly unable to prove that there's more data than was unencrypted, multiple sets, multiple passwords, or whatever.

Then, when you're being beaten with a rubber hose, you can 'safely' spill your guts.

-1

[Anonymous Coward]

-1 erqhaqnag

Re:I realized something while reading the article.

[grahamsz]

Say tommorrow someone discovered an efficient technique for computing the prime factors of a composite. That would blow RSA and probably DSA out of the water - rendering most parts of PGP/GPG worthless.

Unless we have other asymetric ciphers to fall back on, then e-commerce would be wiped out.

Additionally algorithms with very low computational requirements are of particular importance since we need encryption that can run on smart cards, but cant be broken by super computers.

Smaller signatures?

[DraconPern]

Anyone know if it is possible to create signatures that are smaller? Say 64-bits?

Re:Smaller signatures?

[grahamsz]

Yeah there's no reason they cant be as short as you want... however with a 16 bit signature you could probably find another message that matched it in a few minutes on a fast system.

Re:Smaller signatures?

[tomstdenis]

You are limited by the b-day paradox though assuming all k-bit signatures are equally likely...

Algorithms based on quadratic equations [QWARTZ comes to mind] are usually touted as "super fast and small" and usually turn out to be just small and insecure [or otherwise too obscure to implement].

If you want to lower the size of signatures used in your system redesign your system. Do batch signatures for instance.

Tom

Re:Smaller signatures?

[Anonymous Coward]

The shorter your signature... the smaller your key, and the weaker the signature. ECC can produce pretty small signatures sometimes, but even then, it's possible to get bitten by Pollard-Rho if you just plain don't use enough and assume that small can be as small as you like. (Hello, Microsoft.) Even more exotic sig schemes are... dodgy, quite a lot of the time.

A 64-bit hash, even perfect, would not only get birthday collisions in the wild, it would be brute-forcable. Not a good foundation.

Not really the best intro for crypto

[Gentoo Fan]

I'd point people here first, then to a few other links that other people have pointed out. The article linked is a bit terse for a newbie.

Re:Not really the best intro for crypto

[brix]

The cryptography.com faq is just a "coming soon" index -- Not terribly useful at this point.

Clarification on web-browser security...

[xquark]

>>The present generation of web browsers use 128-bit keys
>> so cannot be considered secure against a determined
>> and sufficiently well-resourced attack.

The 128-bit there is the symmetric cipher key length, RSA is
used for signature authentication and not encryption, key
exchanges occur via hand-shake algorithms ie: diffie-hellman
and derivatives there of...

a 128-bit symmetric cipher is actually very strong, for temporary
transit data ie: purchase data, cc numbers etc.

Arash Partow
__________________________________________ ________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net

Re:Clarification on web-browser security...

[twiddlingbits]

The 128bit encryption is strong, but Diffe-Hellman is subject to a "man in the middle" attack whereby you can spoof the key of one side to the other and then capture the encyrption key. Authentication of sender/recipient to each other has to occur via something like a digital signature before the keys are sent to prevent this sort of attack. Is that what you meant via "handshaking"?

Sosumi, McCartney!

[Chris Tucker]

"When I find myself in times of trouble, PKZ he comes to me.
Speaking words of wisdom, 'PGP, PGP.'"

Good primer? Bah.

[Tenebrious1]

I got lost at "responsible data managers". WTF is that? I haven't heard of RDMs before...

Re:Good primer? Bah.

[Anonymous Coward]

ROFLMFAO! Good one...

Ahhhhh crap,

[Gentoo Fan]

I copied the URL from the wrong tab. Anyways I found a good site starting at GnuPG's site. Silly me, do a preview next time.

known plaintext attacks?

[brlewis]

The primer seems a little overconfident about random ciphers being generally secure. Is it safe to say that most ciphers in use today aren't vulnerable to known plaintext attacks?

Re:known plaintext attacks?

[capilot]

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.

Re:known plaintext attacks?

[dtfinch]

The author's bio says he's a geophysicist.

Re:Comprehensive list of unsolved codes and cipher

[Timesprout]

They are not unsolved codes, they are my drunken slightly rambling slashdot posts complaining about the inequity of life and how truly evil women who wont sleep with me are.

Someone has been reading too much Cryptonomicon

[finkployd]

f you just want to deter prying eyes a substitution cipher using multiple substitutions and several different substitutions schemes offers a reasonable level of encryption for virtually no computational effort. (This is the way Enigma works and after all, it did take Alan Turing to break it).

The Poles broke it, they even invented the "computers" (bombes) that automated the further breaking of it. Turing (not to diminish the contributions he made to BP) really just vastly improved on their methods and created a much more sophisticated machine to break it.

Finkployd

Re:Someone has been reading too much Cryptonomicon

[ACNiel]

Can you supply a link. I was not aware of the Poles role in the breaking of Enigma, what with all the movies one sees having no bearing on the truth.

Re:Someone has been reading too much Cryptonomicon

[freaks_and_geeks]

Won't supply a link here, but Simon Singh's excellent "The Code Book" provides a large level of detail about the Polish contributions to breaking Enigma.

Ahh, what the hell, I _will_ supply a link here. Or, just google "Rejewski Enigma".

Re:Someone has been reading too much Cryptonomicon

[kalidasa]

Not a link, but *Seizing the Enigma*, by David Kahn (of "Codebreakers" fame), has a complete account of the decryption of Enigma, including the Polish decryption efforts. I think the Poles broke one Enigma variant, but couldn't get beyond that, and then of course they were occupied, though I think the "bombes" got out intact somehow.

Re:Someone has been reading too much Cryptonomicon

[bloodhawk]

Yes most of the movies are crap. The Poles broke it long before the brits were even aware it had been done. Then just before Germany invaded the poles met the brits in a cabin in the woods and had the machines they created smuggled into england where Turing and dozens of others worked to improve the speed with a better machine.

Re:Someone has been reading too much Cryptonomicon

[MartinB]

...and it should be noted, breaking it at any useful speed required the use of cribs - standard plaintext fragments (like the "Heil Hitler" signoff) that gave the breakers a start with each day.

Re:Someone has been reading too much Cryptonomicon

[FoeQueue]

http://en.wikipedia.org/wiki/Cryptanalysis_of_the_ EnigmaEnigma

Re:I realized something while reading the article.

[Anonymous Coward]

"PGP" and "GPG" aren't ciphers. They make use of them. They support multiple ciphers, which is a good thing if one is compromised. At least you have the ability to choose a "known" safe cipher. You also have ciphers with a different key size (112-bit 3DES, 192-bit AES, etc) so you can choose that as well.

As for the OTP, that's a completely different type of encryption. The key length has to be the same as the message length, and has to be completely random. That's not practical in the real world.

Weakest link

[lilmouse]

Ha! The weakest link will always be either the user or the administrators who are open to "social engineering".

I am *still* amazed that I can do things like verify who owns a bank account, get passwords reset, change addresses...

--LWM

Re:I realized something while reading the article.

[zerguy]

yes, but we already have other ciphers to fall back on. If someone figures out how to compute prime factors, we can use those, and start developing new ones, but that is very unlikely to happen.

And why is my article modded flamebait?!

random & pseudorandom pads

[cant_get_a_good_nick]

Random pads with truly random data is unbreakable. The few times it has been broken has been due to human error (reusing the same random data stream). The US tracked some russian spies with this, they reused pads, and we found out there was a mole in the atomic bomb program.

That said, paddign with pseudo-random data is very unsafe. Breaking this type of encryption is typically one of the first homework assignments in cryptography courses. The article is either very fuzzy on this distinction, or plain out wrong, depending on how you read it.

Re:I realized something while reading the article.

[zerguy]

Forgive my confusion of PGP and GPG being cyphers. I got my point across, I believe. IANA Cryptographer. And if OTP's are not practical in the real world, then why did they work so well for the military during the cold war?

Re:I realized something while reading the article.

[tomstdenis]

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

Re:Comprehensive list of unsolved codes and cipher

[cpeikert]

If after reading the intro to encryption you are so inspired to try to crack one, I highly recommend this list...

The problem with challenges like "crack this uncracked cipher" is that the challenge is not realistic.

Most of these codes/ciphers give you no idea the process behind how they were generated. That's unrealistic: usually an analyst will have the algorithm that does the encryption (if not the key itself), either via open-source, reverse engineering of a public binary, legitimate purchase, or espionage.

Most of these challenges only give you a tiny piece of ciphertext. That's not realistic: if you're trying to break, say, SSL, you'll be able to get your hands on megabytes of transcripts, and you'll even be able to generate ciphertexts that correspond to plaintexts of your choice.

Most of these "ciphers" don't generalize to arbitrary messages. That's unrealistic. Sure, someone can design some ad-hoc cipher to encrypt the location of his buried treasure using landmarks, clever puns, and weird symbols. That's a far cry from being able to efficiently encrypt an arbitrary TCP/IP stream.

SERVER SLOWING DOWN

[zoloto]

try this link
http://www.techworld.com.nyud.net:8090/security/fe atures/index.cfm?featureid=993

Coral Cache works!

SETI noise

[3770]

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.

Re:SETI noise

[maxwell demon]

Unbreakable.

And the Titanic was unsinkable.

Indeed, this code can be easily broken by just getting one of the CDs and making a copy of it. Yes, this needs physical access to the CD, and is therefore harder (and you can add extra levels of security, like putting that CD in a safe [and hoping that your friend keeps his copy secure as well]). So it's still a very secure code. But unbreakable, no.

Re:SETI noise

[saigon_from_europe]

1) Get 600MB of random noise data from listening for extra terrestrials from for instance SETI.

Don't do it!!! Simply, it's not safe. What if you take signal from some extraterestial inteligent species? That signal will not be completely random, and someone will be able to break it...

Re:SETI noise

[3770]

I agree that it isn't completely safe. But you didn't break the encryption. You stole the key.

Re:SETI noise

[Knight2K]

This scheme is more commonly known as a one-time pad. Basically, you need to generate a set of random data that can be combined with your plain-text. A common implementation used to be pads of onion-skin paper with blocks of random letters on them. Onion-skin was used since it was possible to generate pairs of pads using carbons and also because the paper was easy to destroy. The pads usually had something like the date the pad was to be used on them.

Often these systems were broken because the pads were misused: the same pad used multiple times, or the same pad used with some variation.

IIRC, the scheme you are purposing is similar to the way that the red telephone communication between the Soviet Union and the US, as well as embassy communications, was secured. In that case, special vinyl records were distributed that had to be started at the same point. The length of the record determined how long you can talk.

This essay on Bruce Schneier's site highlights one of the chief weaknesses of the one-time pad: the key distribution problem. You have to figure out how to get your friend's CD to him without being intercepted. You also have to be sure that the computer that generated the CD's wasn't compromised; someone spying on your machine could just log what audio file you used, copy it, and generate their own key CD.

Considering that a CD can only hold around 700MB (for a standard audio CD), I would say the key space is small enough that even if an attacker doesn't know your position choosing scheme (your description of the system states that the position is part of the message, so I'm being generous here), it should be possible to brute force the message if he somehow gets access to the key.

Another problem is: you may suspect that you are being watched or the system is compromised, but your buddy may not. How do you communicate that information to your friend, especially if you aren't supposed to be in contact with them in the first place?

If the attacker has your key CD, he could send an encrypted message stating that you (the legitimate user) are the attacker? Then who would your buddy believe?

The benefit of public-key cryptography is that it limits the amount of data that needs to be shared in order to communicate. The keys used for encryption never leave the possession of the person doing the encryption. It is also relatively simple to generate new keys.

Of course, man-in-the-middle attacks can still happen. But if you can establish the first public keys that you and your friend will use in a secure manner (e.g. face-to-face meeting), subsequent public keys can be encrypted using the last trusted key, or by using other key sharing schemes.

Re:SETI noise

[myukew]

and - not only he gets your messages - he even becomes rich for finding ET!

Re:SETI noise

[twiddlingbits]

The solution is simple, just encryt the whole CD of random noise with something simple/free (Like PGP Disk) that requires the input of a pass phrase to access the CD. Then chose a 6 to 8 word pass phrase using random 8 to 10 letter words from a dictionary or use a phrase ONLY you would know. So, if the CD is stolen the data is unusable. You can buy off the shelf products (like PointSec) that will do this to your entire hard drive as well if you want to keep the data online.

Re:SETI noise

[Monf]

Didn't they use to do the same thing with vinyl records? (except for the seti part...)

Re:SETI noise

[kalidasa]

Or, to translate this more simply, encryption based upon a one-time pad is not breakable without stealing the key.

Re:SETI noise

[Lord Ender]

Actually, somebody else could be recording the SETI info. He could then XOR ("superimpose?") his message over all data generated by SETI until he comes up with plain text output. That would take a finite amount of time.

Re:SETI noise

[capilot]

Even if you reuse it it is hard

No. If you reuse it, it's easy to break. The Rosenberges went to the electric chair because some Russian spy reused a pad.

Re:SETI noise

[roystgnr]

This message can _not_ be deciphered if you make sure that you never reuse the same random noise.

Right - assuming the noise is random. Your suggested SETI data isn't entirely random, and of course most convenient (pseudo)random number generators (e.g. /dev/urandom on Linux, rand() and random() in libc) aren't really random. Just because something looks random doesn't mean it is.

Even if you reuse it it is hard.

Define "hard". If you reuse your random numbers, can't an attacker just take two of your encoded messages, XOR them together (which removes the random numbers from the equation), and start searching the result for XORed combinations of shifted dictionary words?

Re:SETI noise

[3770]

I envisioned reusing it by of course not starting at the same place and by possibly skipping ahead using some tricky and unknown algorithm, possibly using large tables with random data, that is available on the same CD.

I guess SETI might not be completely random. I was just trying to make a point. Someone suggested geiger counters.

Re:SETI noise

[Anonymous Coward]

This message can _not_ be deciphered if you make sure that you never reuse the same random noise.

And of cource, you'd have to be the only one who HAS that particular noise you've harvested. From the top of my head I can think of three dangerous assumptions you've made.

1. You assume that no one can intercept that random data in transit and that you are the only one who it was sent to.
2. You assume that SETI doesn't have your random data stored somewhere, in which case I could steal it from them (assuming of cource I wouldn't be able to steal it directly from you).
3. Also, you are assuming noone can "taint" your random data by injecting something into it while it's in transit (complex maybe -- but doable).

It might seem like a good idea to use SETI data but I can assure that it's not.

Re:SETI noise

[plover]

If your data is truly random, the starting point will be irrelevant to the security of the scheme. Therefore, in the interest of key maintenance, it would be best to start at the beginning with the first message, and always begin the next message at the point where you previously left off. This ensures that you use all the key material once and only once, and as soon as you run out you destroy the disks.

For truly random data, a Geiger counter is indeed a great device to use. John Walker has built and documented a device called "Hotbits" which he uses to generate truly random numbers.

If you were to accidentally reuse a piece of the key, the plaintext would be quite easy to recover. For more on the subject, and how the FBI knew that the Rosenbergs were guilty, see the NSA's Venona site. For an easier-to-read treatment of the subject, I strongly recommend a third party analysis, such as Venona: Decoding Soviet Espionage in America by John Earl Haynes and Harvey Klehr (Yale, 1999.) In it, the authors explain why the Soviets probably re-used their one-time-pads.

What is also interesting to note is the authors' conclusion that the 'code names' the Soviet agents used actually turned out to be one of the best security measures they used. The people in the messages were identifed by a tedious procedure of compiling a list of suspects, then finding additional information that pinpointed their suspect. Julius and Ethel Rosenberg were identified by their relationship to Ethel's brother, David Greenglass, in a background 'biography' sent to the KGB by their handler. There were at least 20 other moles in the Venona decrypts that were never publicly identified because the NSA could not deduce their real identity from their cover names.

Best class in college

[silux]

One of my favorite classes was clasical algebra. I'm always glad to see some info about encryption and how it works. Thanks guys

Re:I realized something while reading the article.

[Anonymous Coward]

I'm sorry but what part of rSOuSdrCxMg99vfs/2PHdYgx4yL2+ZiLTj2jDLSr8JgtHWOzOr xZ+RfGRialMKvZ zM7n+MIamILwHIZUE57DVGVBOavWoTAAcTuV4KIKSXRLqL/s04 SNxfEOZ/ZhmYdS Rc4wCqLOEQNJMO9J+9CgFmIjwcsKMLxRFSn1vQksGAna1TQnd2 ialyviaK5XEybj A9+6XLfx/Nh0ZM2I/u9lSGZBKCBzh9tOfL6zNa8svjGgHPQnEo GThv7JLzX56S2r nbk/7Wa0D9urgVTNCmkW8/pchjxNjmS8QGiAXiqStRS3ZWizNH CkQCyh2+hL9hR8 OLrWK3eY5GaQz8hK2J5SrqmlH0+IkIDPcEy7taB2xpsqRq5WTK eDbXSqVPn64qGM ag9zksMHHJluAdSewxPpx0sLPuEKyxhm0fydOUTypNVDiz3wV7 bjDgNJWiYUdwcM DIn7NfO8pMJpmNXxt+RZcVoeqRhxQsZVxUgnLvy003N0bZy4gp I+yJe0/UQPS3zY tYBy4ntmrb8b9PNm+sAIc2kGQ+TUVad6Z4xT2BoDm70YOCVP7u mqCCrfwc019HHo DUABcCTC/v3Wi/hbbt/53QYIVqDRBbLevOBzLMUJn6h3qeO+iB /v5euG5KBpITY1 q3G7cAS9ANPBR4k17Hlbrhfb1XTHpXqcKvgDznAl5+CkZwGYBQ JLKHqIjjGzZWo1 infoh+M24ncq8qLOQLkg6bHy9RgiSHhgVnzePOkMqXD3/Q5dES lfDKdegWOky4dg z6PEJLoiEGN7EY2XvKI6tYnbblO0OB+7AJTso8TOH4ZFsX3DL/ jEvQ== didn't you understand?

Encryption != Cryptography

[kristoferkarlsson]

Digital signatures definitely have something to do with cryptography but is in general not related to encryption.

Re:Encryption != Cryptography

[evilviper]

Ah, that's what I was missing, then. Thanks.

Re:I realized something while reading the article.

[ACNiel]

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.

That does it

[Anonymous Coward]

Im off to Nth. Korea

Well

[Prince Vegeta SSJ4]

-----BEGIN PGP MESSAGE----- Version: PGP 8.0.2 qANQR1DBwU4Dj5r5ZoruKWUQB/9FfBiGMyyZYrgg9jaezAFPQv EBWTNIl/J8mIK+ 1lUy8q+oJYM3e+LTogfJaH1oEKplFnKuhhtz1jrEs0NmbOMB9X aO9EggppEw0r8S W/JjKyGRySaddz29+GYL28TCW3RSKzXkavn+vzLmeLnWT5h+Nw 8PJjdAAvKSKvFy Vp8lNFIhug7ZiX95dZrMfQE7lwVhFYu85uWWqzORwc/6it/1zD 6z6uuf5mK0jobJ rMtSWbdJNtjAWkl8E2MaBVBeNBxiUZyN9FMzuLuadI+CUdUehG bXiQWkmGXy4mF0 bqSQILCycrKi3yPrLNtrimnGf48oRGjvN7vKywnMeKXoJRjdB/ 0bJESQ40nv6GLx CDTKt7Ki4IRjXMrx/1SHqlUDwRR5Wb1pSOW+huAaAr7IceHlVM ZLBBddqBr04LjU qiXQs18WM9LmDFyxhxw+1JkgPcDI7X8Zzl+JQGiadOg1lnz9sA h6hJSUOEDJimsv wXpgANO6pEdUwaCMhzzQENPywHn9is+IkXnwdZeXNDn3V8ECzG j4Zxz4pWE23h74 EINwmbvUaSIWhD4dmR3xEyXvyuXaTxdj/co7mYLUpdlQgThEvR ZvBGnY+QMLRuq0 RhC7zdUB3s0affXolmvOeCm1nAwPlJlbYpDoDpf6IWYRjtkW2P jpffspd1KZPWP/ PQwPGYwU0sAoASaEO1siggkPO3Mb7Yt4kJ8Xexa2fGloU1u3wr 0jLCpl7os7sEwe Tv/C46evluld7zBJ03QD/lEwhv/7TMXoblHGW0p9esL3w+hA4I UHKinjquLvM21e pf/m6JJLQL9yjRlaOa8qHVUvd06OMTiI5n90Yt7FlvMT7LjPZn 1lq0fPFfhI7ZXS +wKHET4r79tLGsUgamDP+F0JZ7nC3dlwsuQXHx7Ttb8bg8YE49 HdnZmw+jMbqCCO AkpIl7XDBuBFWmUSpEO8gqpC7lMCecO6k2ujP9KklpCo4IEXQt KH41U1qm54s3mY +w== =ow71 -----END PGP MESSAGE-----

actually they did define p / q / n.

[Anonymous Coward]

specifically "p and q are the factors of N", from fundamental theorem of mathematics. I didnt rtfa so i dont know if they define d or e.

Re:actually they did define p / q / n.

[Anonymous Coward]

They defined p and q as a function of N, but they never defined N.

IANA cryptographer, but I've read some Neal Stephenson and Dan Brown.

I'm guessing that:
d is the private key
e is the message
p and q are the prime factors of the public key N

Am I even close?

Re:actually they did define p / q / n.

[Anonymous Coward]

digging through the web. here's a bit better explanation. http://www.di-mgt.com.au/rsa_alg.html.

Mel & Baker a good crypto book

[Coop]

Cryptography Decrypted by H. X. Mel and Doris Baker is a good intro to crypto. I found it entertaining and the topics went from elementary to, uh, more than I cared to know. The appendices explaining the mathematics of crypto were interesting as well.

some things newbs should learn about encryption

[brlewis]

If you're going to give a cursory intro to encryption for the masses, I think a less mathematical approach would be warranted. This is not an exhaustive list, but here are some practical questions:

1. Who can intercept my interaction with web sites if it's unencrypted?
2. Who can intercept my email if it's unencrypted?
3. How can I tell if my web browser is using encryption?
4. What do those warnings about SSL certificates mean?
5. Why does Internet Explorer warn me about a page with "both secure and nonsecure items"? What can I do about it?

Re:some things newbs should learn about encryption

[hobo2k]

And the followup question to (5) why does firefox not seem to care about mixing them?

char rot13_program[64];

[Anonymous Coward]

main(a){while(a=~getchar())putchar(~a-1/(~(a|32)/1 3*2-11)*13);}

Just set up a new system

[scribblej]

I just put together part of an ecryption system for my job. I've got kind of a question about it, too --

I've heard that using more than one "encryption algorithm" can open you up to new vulnerabilities...

I need to encrypt certain short string in our database and I'm using 1024-bit RSA with OAEP, but I also need to be able to search for all occurences of a particular sting in the DB, so I'm also storing a (salted) MD5 hash of the same string that was encrypted, since the RSA-encrypted string is different even if the plaintext is identical, but the MD5 hash is the same when the plaintext is the same... I can compare based on MD5s and not need to keep the plaintext or even know what it was...

But does having the same string hashed with MD5 and encrypted with RSA open me up to any problems? Is there maybe a more clever way to address my needs (if I've even described the situation properly...)?

Re:Just set up a new system

[Anonymous Coward]

If you're using the same key to RSA encrypt your blobs, I'd suggest ditching the OAEP in favour of regular PKCS1 ...

Having just MD5 without a salt value opens you up to dictionary attacks and the like.

Re:Just set up a new system

[Anonymous Coward]

I've heard that using more than one "encryption algorithm" can open you up to new vulnerabilities...

Yeah. When you do that, you're basically rolling a new algorithm.

But does having the same string hashed with MD5 and encrypted with RSA open me up to any problems? Is there maybe a more clever way to address my needs (if I've even described the situation properly...)?

You're doing MD5 hashes of the string, and encrypting it (the string, not the hash)? Sounds fine to me.

Re:Just set up a new system

[Anonymous Coward]

Elaborating on the above.

Searching for a particular string you'd have to do the following

LookUpValue(RSA Encrypt(Hash(string to search for)))

OAEP introduces randomness in the padding => hence no signature ever quite looks te same => impossible to do lookups.

(This provides extra security for services which must place a lot of signatures over a prelonged timeperiod)

Re:Just set up a new system

[chialea]

If you want to do this really "right" in a way that's probably massive overkill for your application, I wrote a paper on doing this. http://www.ece.cmu.edu/~reiter/papers/2004/ACNS.pd f

Someone's using this paper for a class, so there are slides for it: http://www.google.com/search?hl=en&lr=&c2coff=1&q= +site:www1.cs.columbia.edu+private+keyword-based+p ush+and+pull

If you're really interested in search over encrypted data, email me what you need to do, and I'd be happy to take a look at it for you.

Lea

Re:Just set up a new system

[chialea]

Oh, and I wouldn't be using MD5 anymore, if I were you. SHA-1 has only been cracked to ~36 rounds (without IV quite a bit more), so it's currently considered secure, though people are looking at replacing it quite quickly, based on the results presented at Crypto this year.

Lea

Re:Just set up a new system

[plover]

You're absolutely right in that an adversary can play one system off the other. Having the strings hashed with MD5 is your weak point.

You mentioned that these strings are "short". "Short" means the string space can be brute forced much easier than the hash. Lets say that an attacker concludes these short strings you're encoding map to Visa account numbers (a typical application.) A Visa number, for example, has only 14 unique bytes to brute force, and even then the search space drops to 11 digits when you factor in 4 digit bank numbers (there are even 6 digit bank numbers, but I'll stick to 4 for the example. And since many bank cards are regionally based, if a ZIP code field is present there's a reasonable chance that one of that ZIP code's regional banks may have issued the card.) So 10 possible values for 11 digits yields 10^11 possible values. 10^11 is not a particularly large number of MD5 hashes to generate to determine if a value was encoded -- a high-end dual Xeon desktop could probably search an entire bank's account number space in about six minutes or so. Picking the top 5 national Visa bank numbers plus the top 5 local-to-the-ZIP-code bank numbers means a reasonable chance at a break in about an hour.

I really don't know anything about OAEP (other than that this RSA page says, "This means that to construct a valid OAEP encoded message, an adversary must know the original plaintext." That doesn't bode well for you. If the attacker just figured it out the plaintext by a brute force search of the account number space, then he's got a new wedge into your systems.

That's why mixing crypto systems without a full understanding can seriously weaken security, rather than enhance it.

Re:Just set up a new system

[scribblej]

Thanks for the analysis. I'm glad I asked... now I'm going to have to figure out the Right way to do it. :/

Re:Just set up a new system

[plover]

You're welcome. If it's any consolation, what you're trying to accomplish is a very difficult problem to secure.

Something else that you might consider that isn't necessarily going to help much is to add a secret key as an Initialization Vector (IV) to the hash. An attacker simply observing the system can watch "12345" go in and see "aBcDe-NaCl" come out ("NaCl" is the salt :-), and build his dictionary that way, without performing a single cryptographical attack. Of course, this requires more active participation than simple analysis of a stolen database, so you'll have to judge your risk tolerance level for yourself. If you trust your computing environment can't be compromised (and you're trusting of your insiders) then it may be an acceptable risk.

Keep in mind that there are many ways of attacking this stuff: using his own personal Visa card just prior to stealing a copy of your database, an attacker can make an educated guess that the newest-timestamped row in the table is his own card, giving him a known plaintext wedge. Even if your rows aren't time stamped (not even in the super-secret hidden system columns), the addition of the row may end up in a SQL recovery journal file somewhere, and the attacker might reasonably expect his data to be at or near the end of this log file.

( Yes, all these are the tricks of a psychotically determined attacker, but what other kind are you protecting against? )

And my earlier analysis was pessimistic, by the way. My desktop can search a single bankcard's entire 10^11 account number space in about 156 seconds, or just under two and a half minutes. That means I could perform an exhaustive dictionary attack on all 750 billion* potentially valid Visa account numbers in about 2.5 hours.

* based on a not-publicly-available 2003 list of valid Visa bankcard ranges.

Re:I realized something while reading the article.

[Bill Dog]

And why is my article modded flamebait?!

Simple, because you failed to include at least one of the following in your post:

• M$ sux
• SCO sux
• Walmart sux
• Capitalism sux
• Bush sux
• Ashcroft sux
• That's why I switched to Firefox
• That's why I switched to Linux
• I for one welcome our new...
• Article mirrored here [www.innocentsoundingdomain.com?redir=goatse.cx]

A better introduction

[aaronvegh]

From PGP's site: How PGP Works.

It talks about the origins of crypto a little, and leads into public key encryption, a field I have been trying to learn a little more about. Much better article than the parent!

Re:I realized something while reading the article.

[nwbvt]

How do OTPs work? Each side has an identical stack of pads which are used to encrypt and decrypt codes. Each time one pad is used, it is destroyed. This is mathematically unbreakable, though there are methods of cracking the code that do not involve mathematics (such as stealing a copy of the pad).

This may not be too big of a problem if we just have two people who need to send a few messages to each other as long as both can keep the pad safe, but it fails horribly in other situations. For instance lets say I want to send my credit card number to some online store, but I want to make sure it is encrypted first. Lets say the store writes a random pad for us to use. How do we share it? Somehow they have to get it to me without anyone else seeing it. But if we had a known secure method of communication, we wouldn't need the pad in the first place, now would we?

Public Key encryption solves this problem by allowing the store to develop the code and send me a key that only allows me to encrypt it (it can't decrypt anything). Thus it doesn't matter if the whole world intercepts the key, all that would allow them to do is encrypt more messages. It doesn't help them decrypt anything. Of course all these codes are usually based on problems that are mathematically hard to solve. If an easy solution is found (as with knapsack cryptosystems like Merkle-Hellman), then it becomes easy to crack the codes, and thus we need to have other codes available. In addition, many decryption algorithms are very slow and thus work is done on more efficient algorithms (though slow ones like RSA actually can be sped up by only encrypting a private key with the public key scheme and using the private key to encrypt the actual message).

Hope that helps.

Re:I realized something while reading the article.

[nwbvt]

"...but that is very unlikely to happen."

Actually its not. There is an efficient algorithm out there for factoring numbers into primes. The only problem is that it requires technology (quantum computers) which doesn't exist yet, but which is on the horizon.

"And why is my article modded flamebait?!"

Because mods are jackasses.

And now to toot a small horn

[VernonNemitz]

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!

Re:And now to toot a small horn

[chochos]

OK I checked the webpage. So let's see if I got this right... this thing uses a key that must be at least 8300 bytes long? yeah, that is SO practical.
And you need to generate 105MB of prime numbers. Which are supposed to be random. And these are used for encryption/decryption. It doesn't sat in the page, but I'm assuming you need these same numbers for decryption... so if I encrypt something with this method, I have to

1. Send the key file to the recipient first
2. Make sure the recipient has the exact same 105MB of prime numbers I have

It seems to me that a 1-time pad might be easier to use (and I'm pretty sure it will be safer).

Re:And now to toot a small horn

[VernonNemitz]

Well, the Web page was intended to be an introduction, not a technical description. If you want to know more about how the "key" file is used to select primes pseudorandomly (8300 bytes --> approximately 1000 primes minimum -- AFTER which they are used to generate pseudorandom numbers), read the HalfBakery page, or download the .zip and study the "cryption.c" source code file.

Regarding your points 1. and 2., you can pick any key file you want off the Web, and just tell the recipient the filename -- maybe an .MP3 -- in a casual conversation (FIRST time and other random occasions; after that you mostly just encrypt the name of the next key file in your current secret transmission), and if the recipient has the downloaded the same "Primary Cryption" program suite/version as yourself, then he/she will indeed be able to locally generate the exact same library of prime numbers as yourself. The library is simply ALL primes that fit in 32 bits, after all (203,280,221 of them); it only exists so that the encryption process can obtain a thousand (or thousands) Nth primes more quickly than generating them on the fly.

Crack this one nerd

[Anonymous Coward]

Wow that is pretty 'leet of you to do all that cracking. I bet you can't get this one

alksjf opiweop poweirqq sdnbfe!

isyay isthay ayay odecay?

[NewtonsLaw]

Iyay etbay obodyyay ancay igurefay histay utoay!

Uggerbay, hatway oday ouyay eanmay "veryeay oneyay owsknay igpay atlinlay?"

Re:isyay isthay ayay odecay?

[Starji]

ouyay ispelledmay 'obodyyay'.

You make a valid point, but

[Anonymous Coward]

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

jA0EAwMC/qVntvR77YRgyenJbm5WgZgN7Ae iprO2rdL3eiWPnzpm0A96RXRQYyJL
Tn11Oyzynt4fLImyYGl LPXgCh3plwxFxZ4mH5rQQh3wUnnrlgFxQHD8UdzQPCFC4
ol6 Cr+KJnEyvO9I+oNDjgoND72GL7GvkPC6fAWp+MzIFMAvO4XWmk zifIJXNrUPW
l22Fa/zJEjzkHKTwZRnqNMRF7CPRcvyfDm1yk uS0e4P/j/qLgWnu+CyVc1u6LGHa
/YXC4kfLBaLP56n3JE645 LtAW82cGS6WuZGl4hGcwY/IHo5gmSqh4IPdgRYYwIAA
LYcli L6STfQwDg+cwwQgOAFdXkdCARwrp4SqXEy8y5Swg7B0UUtVFLE jT8ONENpo
mL0yipE/52trzkzTOfujKVDTI9wAFNmySRq8wuQ AhS0FvWc5+rj/DMAa/PRmJ0gv
HJHvuYht+oKKlzOHL/iKaSU OmQSyDhaaJo5CUs/PAoCex7D3x7U8y/ylp691fbAx
MleZ9QK 0lLl1kVfSLVKJPduK5e3jdCoQy5kcXJvuPlh5R1Gd82fbNCEt0 JssYVNn
SJVT/9cgdW7fn/sANT9oThJ1jxY3dRL8w4pj7uF5G 1ozPCxdvrx96GVJrRf6fVoJ
HgI+Qh6YKXAmmgaDwofI7SwLK Ov+zzekVwrs5mAIZxc+UIdtnwzxJ2mkHnjFbJIS
9B0FMorEI cuiTY+dyrSfanCIgJBrYxZ7FPu8mS32KA==
=5K8o
-----E ND PGP MESSAGE-----

Re:LastMeasure hits the 100000 watermark

[Anonymous Coward]

Lbh jvyy qvr nybar.

Source

[jcuervo]

I remember hearing they got around the crypto export laws by having it printed, instead of on floppies/CDs. Freedom of speech/press laws take precedence, apparently... clever. :-)

Talking about encryption

[ShecoDu]

Would somebody give me a clue about solving the level 5 unknown quest of arcanum.co.nz?

It's about making the script think you're really from new zealand, spoofing headers, using proxies and such. I haven't been able to solve that one, i already got all the other 3 from the level 5.

I learned a lot about encryption in that website, they used the ceasear cypher, xor encryption, and some other methods I didnt know back then. It was fun.

Is some of you from new zealand? I could also use a hand from somebody who has a .nz hostname. :)

Even worse ROT methods:

[Anonymous Coward]

ROT-26:
first post!

ROT-27-X:
aaaaa aaaa!

ROT-Y:
fjtvx vvac!

Re: Credability = Zero

[KillerCow]

About RSA: Current hardware means key lengths should be 1024 bits for complete security. The present generation of web browsers use 128-bit keys so cannot be considered secure against a determined and sufficiently well-resourced attack.

Firstly, directly comparing symetric and asymetric key lengths shows that the authour has no knowledge of encryption. They are not directly comparable since they are used in different ways and have different meanings.

Secondly, claiming 128-bit keys are insecure shows that the authour has no knowledge of encryption. 80-bit keys are widely considered infeasible to break.

Great article!!!

[Gverig]

Impatiently looking forward to next articles in the series, "Blind Typing" and "Introduction to Microsoft Word for accountants". ... information on folding cables is at least less available.

Re:I realized something while reading the article.

[chialea]

Different cryptosystems have different properties, some of which are incredibly useful. These examples are somewhat lame; I just pulled an all-nighter for the eurocrypt deadline.

Example 1: Partially homomorphic cryptosystems. Want to be able to add (or multiply, but not both) encrypted numbers? Now you can!

Example 2: What if you need the set of numbers that your cryptosystem encrypts to have some sort of mathematical structure? (a ring or a field or so on) For example, if you have polynomials where each coefficient is taken from a field, you can factor the polynomial. Trust me, it's useful. I would kill for this particular property right now. You can do incredibly cool things with polynomials. If anyone's interested, I have a brand-shiny-new paper.

Example 3: Key privacy. If I have two ciphertexts, I can still tell whose keys they're encrypted under, unless the cryptosystem is key-private. So evesdroppers might not be able to tell what you're sending to that anonymous remailer, but they can tell who you're sending it to.

Example 4: Faster encryption/decryption and shorter key-length. Randomness can be expensive to generate and transmit. OTP is only practical if you have a reliable offline method of sending key material (and a lot of it). What if your courier is killed? Does that mean an undercover agent can't tell his home base about a terrorist threat? A Paillier ciphertext is twice as long as the contents, but there's a pretty large minimum size there (related to security), and it's only going up.

Example 5: Cryptographers and algebreists won't give up. As of last year, the dollar figure associated with factoring the product of two primes (up to a certain size, which is larger than what most people are using for keys) dropped by something like an order of magnatude. If you're sending information that's very expensive and needs to secret for a long time, you'd better be using a heck of a key. Even so, it's possible that someone might construct a better factoring algorithm. What then? People keep looking at and breaking cryptosystems.

Plus, it's interesting math and fun to play with. We use cryptosystems in new and exciting ways, to make interesting interactions between people possible. (Another cryptographer here has a paper on bribing cops, formenting revolution, and hitting on women.)

Lea

Encryption Primer

[Anonymous Coward]

I like the primer PKE here.

RND number generation and encription cards

[saigon_from_europe]

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?)

Re:I realized something while reading the article.

[Anonymous Coward]

Although the other responses have answered your question properly, I think there's something else that needs attention: you're grading them with a limited scope.

There are a variety of different techniques available to encrypt a message, with each one offering unique advantages/disadvantages. To illustrate this, two examples: async and OTP.

Async (like RSA, etc) is great when you want strangers to send you secure info since there is no need to establish a key set. However, it requires a relatively larger amount of effort to process the message, when compared with sync. A common practice is to exchange sync keys in an async correspondence, and then continue the conversation with sync.

Another benefit is that you can 'sign' a message, but I won't cover that here.

OTP _is_ unbreakable. The problem is that you need to first establish the key AND communicate that key to the other party through a secure channel. This means that the other party is previously known to you and you still need to find a secure channel. The most common method is to deliver the key personally, which can be very impractical.

The other problem with OTP is that you CANNOT USE IT AGAIN. This may seem like a benefit, but the message cannot be longer than the key and renders it impossible to have a continuous conversation using OTP.

One last thing to mention is that any encryption slows down communication. The more levels you add, the longer it takes to encode and decode it.

The general rule for practical encryption is that the security will expire at some date. If you need it to be secret for longer than a year, don't use a cypher that can be broken within a year. And if the info is so super duper secret that you can't ever have the security expire - why have it transmitted in the first place?

Suggestion...

[Anonymous Coward]

wow... this is really just an introduction. If you really want to learn about encryption and decryption, read Simon Singh's "The Code Book." By the way, cipher is spelled wrong.

Re:I realized something while reading the article.

[radish]

No one has ever broken PGP. No one has ever broken GPG.
Correction: No-one has ever admitted to having broken PGP or GPG. Unless you know something those of us outside the NSA don't, you can never be so sure.

Remember, the Nazi's thought no-one had broken Enigma...

Re:I realized something while reading the article.

[Jahz]

People have tried, and it is completely possible to factor ANY prime number.

Basically this task takes a prohibitively long time on modern technology. Even employing the top 5 of the Top500 super computers, results would still take a while (for large primes).

I think that even if it became possible to factor any prime in 1 months time, ecommerce stores *could* rotate their keys on a daily basis until a more permenant solution is developed.

Ideally, we should be using a key system that is mathematically impossible to reverse using a computer ( rather a Turing machine).

Re:I realized something while reading the article.

[Anonymous Coward]

Why do they keep churning out new ones when the ones we have work?

In hopes that their's will become the defacto standard, forcing everyone to pay them patent royalties.

Encouraging the cult of never R'ing TFA

[Anonymous Coward]

This is good primer material for newbs, and a good refresher for fogeys.

After an intro like this, who would want to read it? "Gee, am I a hopeless newb, or a fogey with a bad memory?"

Good For Newbs!

[dshaw858]

This article makes me all warm and fuzzy inside. I'm a big advocate of encryption (especially PGP/GPG), and hopefully this article will encourage some neophytes to start using encryption (such as PGP). I'm not a paranoid geek that sits inside all day, if that's what you're thinking, by the way; I just think that a user has the right to be secure and private.

- dshaw

Re:Good For Newbs!

[Anonymous Coward]

Advocating encryption is useless compared to making it more user friendly. I want to encrypt but I can't.

Ever tried project scim? It handled all the bullshit for me. It was no harder than using any other instant messenger. Unfortunately I can't trust it because its closed source.

I know there is plugins for pretty much everything, but there is configuring and managing keys and bullshit. The masses demand click and drool encryption.

Reusing one time pads

[wurp]

To be more specific:
if you reuse it, then you can XOR the two encrypted parts that are reused (EA and EB) and the result is the same as XORing the text from the two parts, unencrypted (A and B). Therefore the letter & word frequencies are the same as two XORed pieces of english text, and easily recognizable. You can now guess from a much reduced set what the letters are, and you know you got it right when XORing your guess for A against the XORed combination from their encrypted message (EA xor EB) yields the *other* encrypted message (B).

Now you can XOR A against EA to get the random key. So reusing the pad gives up the message from all times you reused it and gives up the random key itself.

OTP is great if you can keep the key secret, have a way to xfer the key, and NEVER EVER REUSE IT. Otherwise, i.e. in virtually every real world situation, it sucks.

Re:I realized something while reading the article.

[grahamsz]

If it were possible to factor any prime in one month then we'd have to get new credit cards every month. That's why it's fine if it takes a few years - since any intercepted data would be good by then.

The way that https works, different keys are used for each session, so they are already rotated more than once a month.

I cant see how we could ever have a key system that's impossible to reverse. The beauty of RSA is that it's simple enough that high school kids can understand it, implement it, and figure out how to break it - it's just a simple problem that takes a very long time.

I would be VERY wary of an encryption technology that was 'unbreakable' since that probably just means the inventor cant see how to break it.

A perfect prime-factorizing algorithm

[roystgnr]

If it were possible to factor any prime in one month

Any prime's factors are itself and one.
</smartass>

Fogeys

[5n3ak3rp1mp]

If I am 32 and the first computer I programmed was a Commodore PET, and I programmed a Rot13 algorithm on the first Apple Macintosh in Microsoft BASIC, does that make me a fogey?

Re:Comprehensive list of unsolved codes and cipher

[Anonymous Coward]

They aren't realistic because they don't apply to encrypting TCP/IP traffic? That's an incredibly narrow point of view you have there.

Very true

[grahamsz]

I was just quoting the parents notion about factoring primes... of course it should be "factoring into primes".

Can i see your top-secret O(1) algorithm :)

And for what its worth....

[imsabbel]

I guess people will never realize that our sun hasnt enough energy to power the brute forcing a 256bit key and continue screaming "moores law will make it insecure!!!!111"

Re:And for what its worth....

[Anonymous Coward]

I guess people will never realize that our sun hasnt enough energy to power the brute forcing a 256bit key...

That's why God made The Local Group.

Solved!

[HexaByte]

The article is really a cipher, and decoded it reads: We really have no idea what we're talking about, but thought that if we threw in enough technobable, you'd buy it.

Password field in SQL:

[Anonymous Coward]

I'm cuurently working on a project which requires me to log users in against a propietory database. The only problem is that the password field is stored encrypted. It's a forward only encryption stored in HEX, the max column size is 30.

e.g.: "letmein!" is stored as "569D67B22D50C257". Can someone tell me what encryption is in use here? It would really help me out.

--TIA

Re:Password field in SQL:

[Anonymous Coward]

It seems kind of like a longshot but that could be a DES hash or more likely it could be the DES or 3DES encryption of "letmein!" (where in all cases, the hashing/encryption will depend on the keys used)

The way that DES can be used for hashing is as follows (and hashing is pretty standard protocol for what you're describing: (a) we take the hash of some pwd and save that, then (b) when the user tries to log in, he enters his password which we compute the hash of and compare against what's stored for that user in our DB (have abstracted out some of the details here as well as some useful options (e.g. salting, ...))):

(1) take "letmein!" and XOR it with some initialization vector (64 bits)
(2) take the output from (1) and encrypt that using DES and some key k (k is 56 bits)
(3) then take output from (2) and *decrypt* that using a second key k' (k' is 56 bits)
(4) then take output from (3) and encrypt it again using k

From this we get a MAC. Or it could just be the DES encryption or 3DES encryption of "letmein!" using some DES / 3DES key.

The reason it's less likely to be the hash using MD-5 or SHA-1 is that with MD-5 the output size is 128 bits (16 bytes --> 32 hex chars) and with SHA-1 it's 160 bits (20 bytes --> 40 hex chars). But there again there could be some truncation going on.

Holiday Inn Reservations

[Anonymous Coward]

That's almost as bad as Holiday Inn's "encryption" scheme for reservation / cancellation numbers.

Remember, all reservation numbers start with "6", all cancellation numbers start with "5". Both are the same length (8 digits). Using the following key:

1 2 3 4 5 6 7 8 9 0
0 9 8 7 6 5 4 3 2 1

In theory one could make a reservation, forget to cancel, create their own cancellation number, call, give cancellation number and get refund. Don't do this. Doing this is bad.

What stupid ways companies keep their secrets.

Next week: How Ryder rent-a truck uses the same key, by make, for their entire one way fleet (or atleast they use to).

LLE

[pair-a-noyd]

Lava Lamp Encryption

http://www.giantlavalamp.com/information/Easy_to_B reak_Hard_to_Crack.shtml

and

http://www.google.com/search?hl=en&q=lava+lamp+enc ryption&btnG=Google+Search

Overblown

[jrivar59]

All you have to do is set it so those asteriky things pop up when you type your password. No one can figure that stuff out.

What p, q, e, d, and N mean

[shostiru]

No. They're from the RSA algorithm. In a nutshell ("number" means integer):

• Generate two large prime numbers, call them p and q.
• Calculate N = p*q. This is a much larger, but not prime, number.
• Choose some number e coprime (i.e., relatively prime) to (p-1)*(q-1), greater than 1 and less than N. Two numbers are relatively prime if they have no common factors (e.g., 32 and 49 are relatively prime, but 32 and 48 aren't). e is, by convention, the number used to encrypt a message.
• Find some number d such that d*e modulo (p-1)*(q-1) is 1. d is, by convention, the number used to decrypt a message. Of course, you can encrypt with d and decrypt with e, too.

That's it. Now, put N and e together in a file and call it your "private key", and put N and d together and call it your "public key". To use them:

• Convert the message into a number n less than N. For example, if N is 40 bits long (worthless, but for the sake of argument...) you could take four bytes at a time from your message as an unsigned 32-bit integer.
• Encrypt n to generate the ciphertext, c, by raising n to the power of e, and then taking the result modulo N (i.e., c = n^e mod N). Send your encrypted number c to the recipient.
• The recipient then takes c and raises that to the power of d, modulo N, to get the original n (i.e., n = c^d mod N). Neat, huh?

In practice RSA takes too much time, so you make yourself a random key, encrypt that using RSA, and you and your recipient communicate using a symmetric cipher.

As to why ((n^e mod N)^d mod N) = n, that's where it helps to know some math. Mathweb or Wikipedia can help you, but having a bit of background in abstract algebra will help.

Some more crypto info/links

[cana5ta]

http://theory.lcs.mit.edu/%7Erivest/crypto-securit y.html

I also have a number of links on a crappy page of mine, that some of you may find informative. Scroll down to Crypto/Privacy etc...

http://allfreightaustralia.com/cana5ta-mirr0r/li nk s.html

-Cam

Parent wrong - VERY UNSAFE

[sytxr]

For the OTP not only does require the pad to be used once, and ONLY once, and it to be sufficiently random, but the pad data also must not be known by anyone else. If you use data recorded for the SETI program, it is certain that that a potential attacker can get to know it. An attacker who considers there may be people incompetent enough to use publicly available data for their one time pad will easily break proposed SETI-based encryption with little resources.

This book has be reviewed here

[floydman]

on slashdot

But the parent submission has the advantage of the book being free, so it is good if you are new to cryptography and want to get your feet wet.

A fun intro to encryption?

[kafka47]

Forget the article, try some fiction!

An oldtime Slashdot favourite : Cryptonomicon, Neal Stephenson.

Includes a supplemental algorithm called, Solitaire, developed by crpto-researcher Bruce Schneier.