Cypher like transformations in the Bible, Jeremiah 25:26, 51,41
The Greeks described substitution cyphers
The Kama-sutra lists secret writing as one of the 64 arts a woman should know and practice.
Cryptography was widely used in Europe during the Renaissance
"It must be that as soon as a culture has reached a certain level, probably measured largely by its literacy, cyptography appears spontaneously... - David Kahn, "The Code-Breakers"
Cyphertext - The message as coded by the cypher system
Steganography - Concealed writing, as if no message is being sent
Cryptography - Scrambled writing, it is obvious there is a message, but it can't be read
Encode - The process of changing plaintext to cyphertext
Decode - The process of changing cyphertext back to plaintext
Cryptographic Algorithm - The mathematical functions used to encode and decode a message
Key - The information which must be kept secret if the algorithm is to provide security.
Key size and security
Symmetric and Public-key Key Lengths
with Similar Resistances to Brute-Force Attacks
(from Applied Cryptography, Second Edition)
Key Length Key Length
56 bits 348 bits
64 bits 512 bits
80 bits 768 bits
112 bits 1792 bits
128 bits 2304 bits
These systems are called Symmetric Key Algorithms
Public Key Algorithms use separate, but related keys for encryption and decryption.
They are designed so it is hard to calculate one of the keys from the other.
As a result, you can publish one of the keys and keep the other one secret.
Anyone who wants to send you a message can encrypt it with your public key.
Only you can decrypt it since only you know the private key.
This feature of public key systems greatly eases the key distribution problem.
Symmetric key systems are generally much faster than Public key systems.
They are designed so it is hard to find an input which will produce a given hash.
They are designed so it is hard to find two inputs which produce the same hash.
Secure hashes, while not designed for encypherment, appear in many cryptographic protocols
Any secure hash can be turned into a not particularly fast cypher.
Encrypting with your secret key acts as a signature.
Normally signatures are implemented by encrypting a secure hash of the data to be signed.
Not only does the signed secure hash authenticate that the data is from you, it also ensures that the data has not been changed (integrity), and makes it hard for you to repudiate your knowledge of the data.
Encrypting a secure hash with a shared symmetric key can provide message authentication and integrity.
IDEA - block size 64, key size 128
RC2 - block size 64, key size variable
Blowfish - block size 64, key size variable
Known plaintext attack
Man in the Middle attack
Rubber hose attack
Bob - Second Participant
Dorothy - Holder of escrowed keys
Eve - An Eavesdropper
Mallory - A malicious active attacker
Trent - A trusted intermediary
Alice chooses a random large integer x and sends Bob X = g**x mod n.
Bob chooses a random large integer y and sends Alice Y = g**y mod n.
Alice computes k = Y**x mod n.
Bob computes k' = X**y mod n.
The agreed key k = k' = g**xy mod n.
Since Eve can't compute the discrete log of X or Y, she can't recover k.
PGP generates a random 128 bit session key.
PGP encrypts the message using IDEA and the session key.
PGP encrypts the session key using RSA and Bob's public key.
PGP sends the encrypted session key and the encrypted message.
Bob gives PGP his passphrase so it can generate an IDEA key to decrypt his secret key.
PGP uses RSA and Bob's secret key to decrypt the session key.
PGP decrypts the message using IDEA and the session key.
Client blinds the serial number with a random blinding factor.
Client sends blinded serial number and coin denomination wanted to mint.
Mint signs blinded serial number with denomination dependent secret key.
Client unblinds coin serial number, mint signature is still valid.
Client sends coin to shop.
Mint checks its database to see if coin has already been spent.
If coin hasn't been spent, the mint credits the shop's account.
Cardholder signs description and encrypts signature and credit card information with bank's* key and sends the cyphertext to the merchant.
Merchant signs description and sends signature with cardholder's cyphertext to the bank.
Bank decrypts cardholder's message, checks signatures and compares hashes of description.
If both cardholder and merchant have signed the same description hash, the bank processes the transaction.
* I use the term "bank" for what SET calls a Payment Gateway
IPSEC includes an Authentication Header (AH) and a Encapsulating Security Payload (ESP), which together provide confidentiality, integrity, and authentication to IP datagrams.
IPSEC can be used to securely connect a roving laptop computer to the inside of a firewall.
IPSEC is defined in RFC1825, RFC1826, and RFC1827. Available from ftp://ds.internic.net/rfc/rfc1825.txt etc.
There are a number of protocol attacks on IPSEC. Many of these can be avoided by using both the AH and ESP features. See Steve Bellovin, "Problem Areas for the IP Security Protocols", The Sixth USENIX Security Symposium Proceedings, USENIX Association.
One answer is that she trusts Trent, who has signed a statement associating Bob's key with Bob
If Alice doesn't know Trent, she may know another entity, Usrula who has signed a statement saying she trusts Trent to associate keys with names.
If Alice doesn't know Usrula, she may know ... and so on to the root of a hierarchy.
The signed statements are called "certificates", and the entities who may sign certificates make up a "Certificate Hierarchy".
Verisign Inc. and the United States Postal Service are setting themselves up as the roots of Certificate Hierarchy services.
Pseudo-random, as are produced by Kunth's random number generators are not good enough.
What is needed for crypto work is real entropy.
Jon Callas will be talking about how to generate high-entropy numbers this afternoon.
Also see: RFC1750 - ftp://ds.internic.net/rfc/rfc1750.txt
US law requires a license to export any encryption product.
US law requires a license to export any authentication product. This license may be easy to get unless the product can also be used for encryption.
Export licenses have been expedited for systems which use RC2 or RC4 with keys of 40 bits or less.
Senator Burns has introduced the ProCODE bill to substantially ease export restrictions.
If you are going to export a crypto product, consult a lawyer.
Diffie-Hellman key exchange is patented by Cylink . It expires April 29, 1997.
Cylink also claims a patent on all public key cryptography. It expires Sept 19, 1997.
IDEA is patented by Ascom Systec AG, Switzerland (firstname.lastname@example.org).
DES is patented by IBM. The patent has expired.
RC2 and RC4 were protected by trade secret. Implementation code has been published on the net. The names are still protected by trademark. RSA Data Security Inc licenses it.
Blowfish is not patented.
ElGamel is not patented. (But see above about Cylinks claim to all public key algorithms).
I am not a lawyer. You should consult a lawyer before using these algorthms commercially.
http://www.homeport.org/~adam/crypto/ for a comparison of crypto libraries
http://www.enter.net/~chronos/cryptolog1.html has a collection of links to crypto resources
http://www.openmarket.com/techinfo/applied.htm - Internet Locations for Materials on the Disks for Applied Cryptography
Crypto++ in C++ by Wei Dai. - Has been tested under Codewarrior 2.0.
"I am a U.S. or Canadian citizen or a legal permanent resident of the U.S. and am aware that some parts of CryptoLib may be restricted under United States Export regulations. I have read and understand the CryptoLib license."
Are you licensed to use the RSA patent?
If yes, give name of licensed organization:
ftp://ftp.rsa.com:/rsaref/README - In the USA
http://www.consensus.com/RSAREF/rsaref_toc.html - in the USA
To subscribe, send mail to: email@example.com with body of subscribe mac-crypto.
To subscribe, send mail to: firstname.lastname@example.org with body of subscribe cypherpunks.
To subscribe, have someone already reading the list recommend you or, as a last resort, send mail to: email@example.com with polite request to join.
To subscribe, send email to: firstname.lastname@example.org" with the word "subscribe" in the subject **NOT THE BODY** of the e-mail.
Let me quote from Philip Zimmermann's PGP documentation:
"When examining a cryptographic software package, the question always remains, why should you trust this product? Even if you examined the source code yourself, not everyone has the cryptographic experience to judge the security. Even if you are an experienced cryptographer, subtle weaknesses in the algorithms could still elude you.
"When I was in college in the early seventies, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful Government intelligence agencies. I felt so smug about my achievement. So cock-sure.
"Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.
"Anyone who thinks they have devised an unbreakable encryption scheme either is an incredibly rare genius or is naive and inexperienced."
The sure signs of snake oil cryptography
"Secret" protocols. Reverse engineering is easy.
Misuse of cryptographic terms like, "one time pad".
Use of terms like, "unbreakable".
Publish your protocols for review.
Make your source code available for review.
For currently useful cryptographic algorithms and protocols: Bruce Schneier, "Applied Cryptography, Second Edition", Wiley, 1996
This document was prepared with a Macintosh version of Doug Englebart's NLS. It is called Thinker and is distributed by Poor Person Software. The URL is: http://www.webcom.com/~thinker/