Please create an account to participate in the Slashdot moderation system


Forgot your password?
Encryption Security

Intro to Encryption 244

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.
This discussion has been archived. No new comments can be posted.

Intro to Encryption

Comments Filter:
  • by JavaLord ( 680960 ) on Monday November 15, 2004 @04:17PM (#10823104) Journal
    svefg cbfg!
  • by DarkHelmet ( 120004 ) * <`ten.elcychtneves' `ta' `kram'> on Monday November 15, 2004 @04:17PM (#10823111) Homepage
    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.

    • by cpeikert ( 9457 ) < minus cat> on Monday November 15, 2004 @04:30PM (#10823233) Homepage
      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.
      • 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.
      • How do PGP signatures work then?

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

        Hash message -> encrypt with private key (TO public key implied..)

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

      • 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.
    • by wfberg ( 24378 ) on Monday November 15, 2004 @04:37PM (#10823291)

      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.
    • 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
    • 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).
    • 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 tha
    • 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 th
  • by yahyamf ( 751776 ) * on Monday November 15, 2004 @04:17PM (#10823112)
    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
  • by NardofDoom ( 821951 ) on Monday November 15, 2004 @04:18PM (#10823115)
    That's easy. Code is what I stare at all day, while Cypher is the jerk who betrayed Neo in The Matrix. Duh.
  • by stecoop ( 759508 ) on Monday November 15, 2004 @04:19PM (#10823126) Journal
    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.
  • Handbook (Score:5, Informative)

    by Ann Coulter ( 614889 ) on Monday November 15, 2004 @04:19PM (#10823133) Journal
    The Handbook of Applied Cryptography: [] 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 (Score:2, Informative)

      by melandy ( 803088 )
      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 (Score:5, Informative)

      by wfberg ( 24378 ) on Monday November 15, 2004 @04:45PM (#10823367)
      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!
      • 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.)

      • Re:Handbook (Score:3, Insightful)

        by swillden ( 191260 ) *

        I'd recommend applied crptography by Bruce Schneier instead.


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

      • Re:Handbook (Score:5, Informative)

        by plover ( 150551 ) * on Monday November 15, 2004 @08:17PM (#10825409) Homepage Journal
        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.

  • ...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.
  • by tokengeekgrrl ( 105602 ) on Monday November 15, 2004 @04:21PM (#10823143)
    If after reading the intro to encryption you are so inspired to try to crack one, I highly recommend this list: []


    - tokengeekgrrl
    • 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.
    • 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.
  • 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?
    • by grahamsz ( 150076 ) on Monday November 15, 2004 @04:27PM (#10823197) Homepage Journal
      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.
      • 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.

    • 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 c
    • 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...
  • 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?

  • by darkstream ( 652288 ) on Monday November 15, 2004 @04:25PM (#10823178) Homepage Journal
    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 (Score:5, Informative)

    by Meostro ( 788797 ) on Monday November 15, 2004 @04:27PM (#10823191) Homepage Journal
    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....
  • Anyone know if it is possible to create signatures that are smaller? Say 64-bits?
    • 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.
  • by Gentoo Fan ( 643403 ) on Monday November 15, 2004 @04:27PM (#10823204) Homepage
    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.
  • by xquark ( 649804 ) on Monday November 15, 2004 @04:30PM (#10823235) Homepage
    >>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.

    • 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"?
  • by Chris Tucker ( 302549 ) on Monday November 15, 2004 @04:30PM (#10823240) Homepage
    "When I find myself in times of trouble, PKZ he comes to me.
    Speaking words of wisdom, 'PGP, PGP.'"

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

  • 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?
    • 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
  • by finkployd ( 12902 ) on Monday November 15, 2004 @04:38PM (#10823301) Homepage
    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.

  • by cant_get_a_good_nick ( 172131 ) on Monday November 15, 2004 @04:44PM (#10823354)
    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 (Score:5, Interesting)

    by 3770 ( 560838 ) on Monday November 15, 2004 @04:48PM (#10823403) Homepage

    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.



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

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

        • 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.
    • 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 (Score:5, Insightful)

      by Knight2K ( 102749 ) on Monday November 15, 2004 @05:33PM (#10823890) Homepage
      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 (Score:2, Informative)

      by Monf ( 783812 )
      Didn't they use to do the same thing with vinyl records? (except for the seti part...)
    • Or, to translate this more simply, encryption based upon a one-time pad is not breakable without stealing the key.
    • 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.
  • by silux ( 28215 )
    One of my favorite classes was clasical algebra. I'm always glad to see some info about encryption and how it works. Thanks guys
  • by Coop ( 9778 ) on Monday November 15, 2004 @04:55PM (#10823460)

    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.

  • by brlewis ( 214632 ) on Monday November 15, 2004 @04:59PM (#10823514) Homepage
    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?
  • 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
    • 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. d f

      Someone's using this paper for a class, so there are slides for it: 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 f
    • 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.

  • by aaronvegh ( 546815 ) on Monday November 15, 2004 @05:26PM (#10823793)
    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!

  • 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 encr
  • by NewtonsLaw ( 409638 ) on Monday November 15, 2004 @05:44PM (#10824012)
    Iyay etbay obodyyay ancay igurefay histay utoay!

    Uggerbay, hatway oday ouyay eanmay "veryeay oneyay owsknay igpay atlinlay?"
  • by saigon_from_europe ( 741782 ) on Monday November 15, 2004 @06:05PM (#10824289)
    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! (Score:3, Insightful)

    by dshaw858 ( 828072 ) on Monday November 15, 2004 @07:04PM (#10824829) Homepage Journal
    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

You are in a maze of little twisting passages, all different.