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.

intro to encryption

svefg cbfg!

Re:intro to encryption

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

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

Re:intro to encryption

I use ROT26, myself.

Re:intro to encryption

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.

Inaccuracy in article?

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?

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?

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.

Much better than that article

I would strongly recommend the Code Book by Simon Singh [amazon.com] 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 [amazon.com] is also an excellent though somewhat lengthier volume

Difference betwen Codes and Cyphers?

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

Garbage

This primer is garbage.

640 bits should be enough for anybody

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 [distributed.net] vs. RC5-64 [distributed.net]. 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

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

Handbook

The Handbook of Applied Cryptography: http://www.cacr.math.uwaterloo.ca/hac/ [uwaterloo.ca] 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

I'd recommend applied crptography [schneier.com] by Bruce Schneier [schneier.com] 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 [counterpane.com] newsletter.

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

Re:Handbook

Actually, Practical Cryptography [amazon.com] 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.

ROT13

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

Eric Rescorla has written a fine book...

...SSL and TLS [rtfm.com], 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.

Comprehensive list of unsolved codes and ciphers

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 [elonka.com]

Enjoy.

- tokengeekgrrl

Re:Comprehensive list of unsolved codes and cipher

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.

I realized something while reading the article...

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?

Re:I realized something while reading the article.

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.

Re:I realized something while reading the article.

How do OTPs [wikipedia.org] 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 [wikipedia.org]), 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.

This is good primer material for newbs

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.

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

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.

Safe encryption

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

Applied Cryptography

Bruce Schneier's Applied Cryptography [schneier.com] 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....

Smaller signatures?

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

Not really the best intro for crypto

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

Clarification on web-browser security...

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

Sosumi, McCartney!

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

Good primer? Bah.

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

known plaintext attacks?

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?

Someone has been reading too much Cryptonomicon

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

random & pseudorandom pads

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.

SETI noise

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

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 [schneier.com] 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.

Best class in college

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

Well

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

Mel & Baker a good crypto book

Cryptography Decrypted [amazon.com] 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

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?

Just set up a new system

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

A better introduction

From PGP's site: How PGP Works [pgpi.org].

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!

And now to toot a small horn

Over at SourceForge [sourceforge.net] is a relatively new Project called Primary Cryption [sourceforge.net]. 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 [halfbakery.com] and at sci.crypt.research [google.com] 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!

isyay isthay ayay odecay?

Iyay etbay obodyyay ancay igurefay histay utoay!

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

Talking about encryption

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

Great article!!!

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.

Encryption Primer

I like the primer PKE here [mycrypto.net].

RND number generation and encription cards

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

Good For Newbs!

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

Fogeys

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?

And for what its worth....

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"

Solved!

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.

LLE

Lava Lamp Encryption

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

and

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

Overblown

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.

Some more crypto info/links

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

Re:Inaccuracy in article?

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 [interesting-people.org]

(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 [mozilla.org]
Also see: http://www.dslreports.com/forum/remark,11293626~mo de=flat [dslreports.com]

A fun intro to encryption?

Forget the article, try some fiction!

An oldtime Slashdot favourite : Cryptonomicon [amazon.com], Neal Stephenson.

Includes a supplemental algorithm called, Solitaire [schneier.com], developed by crpto-researcher Bruce Schneier.