Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Crypto Gardening Guide and Planting Tips

Posted by michael on from the nous-devons-cultiver-nos-jardins dept.

ncostigan writes "Peter Gutmann of cryptlib fame has written a very readable paper on real-world constraints for cryptographers, and points out problems that their designs will run into when attempts are made to deploy them. Also included is a motivational list of extremely uncool problems that implementors have been building ad-hoc solutions for since no formal ones exist."

11 of 91 comments (clear)

  1. Very readable.. by Stormie · · Score: 1, Interesting

    ..except for all the acronyms!! MAC, HMAC, PRF, IV.. is there a glossary somewhere for this??

  2. The Real Question by The+Subliminal+Kid · · Score: 5, Interesting

    The problem I face every day has bugger all to do with the vague under the hood stuff that I see everyday about the inside or crypto engines but the problem of getting my clients to understand that the extra clicks when they send an email, the remebering a pass phrase, and the extra clicks to read incoming email is not only advisable but absolutly necessary. everyday I see lawyers send priviliged material over the internet and getting them to see both that it is going on a electronic post card and there is a solution is a task that has proved beyond me.

    Suggestions from the floor?

    1. Re:The Real Question by plcurechax · · Score: 3, Interesting

      You are right, the human factor is often ignored in building secure systems, though Schneier's Secrets and Lies and Anderson's Security Engineering (Chapter 3 I believe) deals with building entire systems that are secure including making them usable to the human users.

    2. Re:The Real Question by Daniel_Staal · · Score: 2, Interesting
      1. Get two of them together. Have one send an email to the other. (i.e. The Legal Document)
      2. Log into the mailserver. Modify the message in the mailqueue.
      3. Have the other retrieve the email. Point out that they cannot tell that the message was modified.
      4. Point out legal consiquences of agreeing to The Legal Document that has been modified.
      5. Offer to show them how to make sure that doesn't happen.
      --
      'Sensible' is a curse word.
  3. why isn't an implementation standard? by PissedOffGuy · · Score: 3, Interesting

    the article says:

    Crypto designs are often described as mathematical abstractions that, while easy to work with mathematically, require a significant amount of work to translate into an actual implementation.

    i'm surprised by this, why can't the crypto whizzes put together a few lines of math.h and networking code to be a proof of concept? crypto is very much an applied field, so the theorists should include example source in their papers.

    1. Re:why isn't an implementation standard? by chialea · · Score: 5, Interesting

      >crypto is very much an applied field, so the theorists should include example source in their papers.

      Er.. security is an applied field. Crypto is applied non-applied mathematics, basically. I don't /do/ code, generally, and very rarely C or C++, which you seem to be implying should be used. The people who are interested in one are not always interested in the other. Coming from the math side of it, I'm sometimes tempted to say "learn some math and read the proofs before you implement". Not always practical, sure, but just as valid as expecting me to know about networking this'n'that.

      There's also not generally room in a paper for source. Rigorous proofs and definitions can take up a LOT of room. (Everyone who's read the 5x page HILL paper, or one of Dan Boneh's 3x page papers, raise your hand if you want to see source at the end of it.)

      Lea

    2. Re:why isn't an implementation standard? by dracken · · Score: 3, Interesting

      i'm surprised by this, why can't the crypto whizzes put together a few lines of math.h and networking code to be a proof of concept? crypto is very much an applied field, so the theorists should include example source in their papers.

      Well, There is nothing to be surprised about. Many theoretically secure encryption schemes have been broken in practice because the implementation is very difficult. One common pitfall: in theory, often, we assume the existance of a perfect source of random bits. Practically it is very very very difficult to ensure this (remember that part from cryptonomicon - where the encryption is broken because the keys were not perfectly random and there was a slight statistical anomaly ?).

      Also in theory, some schemes are secure only if the keys have some mathematical property. In practice, someone who does not understand this subtle point might make a horrendous implementation. (I dont want to go into the gory details about the field from which the keys should be chosen in the diffie-hellman scheme).

      Even with a perfect implementation, the user is also a very weak link in the chain.There is this famous incident of the more secure german naval enigma getting broken because some ship tranmitted using the new enigma scheme and the same message using the old enigma scheme (which was already broken).

    3. Re:why isn't an implementation standard? by plcurechax · · Score: 2, Interesting

      why can't the crypto whizzes put together a few lines of math.h and networking code to be a proof of concept?

      Nearly all cryptographers do write reference implementations of their cryptographic algorithms. Rivest (RSA, MD4, MD5?, RC4, RC5, many more), Schneier (Blowfish, Twofish), Daemen (AES), Rijmen (AES), and many others write their own code AFAIK.

      The issue that Peter Gutmann is focusing on (cryptographic) security protocols and systems, not cryptographic primitives like encrypting, signing which can be insecure when used incorrectly. E.g. A working RSA implmentation can be written in about 100 lines of C and a multi-percision interger library like GMP or MPI. The problem is that unless you do message padding following a scheme like OEAP your security is not as strong as expected / advertised.

      crypto is very much an applied field, so the theorists should include example source in their papers.

      Cryptography / cryptology falls into a relation with number theory and abstract algebra and computation computer science. Security Engineering is the practice of building secure systems including using cryptographic algorithms and protocols.

  4. What about the other side? by WPIDalamar · · Score: 2, Interesting


    I'm no crypto expert, and many of those suggestions make perfect sense. But I wonder if some of those suggestions decrease the strength of encryption? Perhaps there should be a paper that tells hardware makers how to create hardware to support some of these features that the cryptogaphers want. Or better yet, if the cryptographers could do whatever they want, but then somehoe make multiple versions of their algorithms that follow various subsets of these rules. Then list the drawbacks to using each one. Of course, this would probably create way too much work for those guys.

    1. Re:What about the other side? by chialea · · Score: 3, Interesting

      >But I wonder if some of those suggestions decrease the strength of encryption?

      Most modern cryptography is based on a variety of problems which are believed -- NOT known -- to be hard in certain contexts. Factoring, RSA, CDH, DDH, bilinear maps over CDH/DDH gap groups, braid factoring, CVP, etc. There are people who believe that factoring (and thus RSA) may be poly-time solvable, and thus cryptosystems based on it may be insecure. Cryptosystems based on different hard problems are important for that reason. It's a hedge bet.

      There are also interesting things which come "for free" with certain types of hard problems, which may be very expensive to add on to more common cryptosystems. These properties, for example committment, are used in protocols like Deniable Ring Authentication. This sort of thing follows your suggestion of "a variety of rules", but it's really not possible to list every single cryptosystem in existance and how well it fits in. The authors simply say "(E,D) is a cryptosystem with the following properties", and leave anyone who wants to use it to find the best such cryptosystem, as it may change over time. (They usually do provide a trivial example or a reference, though)

      Of course, if one-way functions don't exist, we'll all be back to information-theoretically secure stuff, and some of these problems will go away :P

      Lea

  5. Political problems just as complex by Anonymous Coward · · Score: 2, Interesting

    I was hoping the paper would touch on some of the political problems facing cryptography, such as how amateur cryptographers in the U.S. should go about posting code for review and humiliation without the black vans pulling up outside.

    The technical environment seems considerably less fuzzy to me than the political and regulatory environment. I have a hard time believing that amateur crypto development within the U.S. is virtually nonexistent, but if you go surfing for code and software, that seems to be the case. Do all amateur crypto people in the U.S. have to send emails off to crypt@bis.doc.gov and enc@ncsc.mil before they can talk to anyone?

    Cryptography is a unique area of computing in that free speech rights don't fully apply. I'd love to be able to post my SHA-based symmetric encryption algorithm and app that even grandmoms can use to sci.crypt and ask many people much smarter than I how much of an idiot I am, but I don't know how to do that without jumping through a byzantine array of frightening federal hoops.