Cryptography Basics

I saw Bankim Tejani of ServiceMesh speak on cryptography at a Wednesday meeting of IEEE (Institute of Electrical and Electronics Engineers). The talk gave a great 10,000 foot view of cryptography in general. Did you know?
 

• A cipher is that which takes readable text and turns it into ciphertext which is either encoded or encrypted. Encoded text may be cast back to readable text by reversing the cipher so to speak. Caesarian-8 is an example of a cipher in which every letter is replaced by the letter 8 places forward again in the alphabet also that "Cat" becomes "Kib" as the T wraps around past the Z two positions back to the B. You can probably see how one decodes Kib back to Cat, but Kib only makes sense if you know what the cipher is!
   
   
• A hash is a cipher process in which text is encrypted not encoded. You cannot cast the encrypted back to readable text. Hashes are used for keeping passwords. To see if a password matches a hashed password, you do not unhash the hashed, but instead you hash the unhashed and see if it matches the otherwise unreadable string you keep for a password.
   
   
• A salt is an additional piece of data that goes into a function for creating a hash to make the algorithm harder for an outsider to decode. Every user account which has a salt for a password should get an independent random salt. The salt doesn't help (much) if it doesn't vary. A code-side object for a user could thus be improved from this:
  User record {
     userid
     pwhash
     attributes
  }
   
  ...by adding a field for a salt as seen below. A salt is an example of entropy which could be defined as something which randomizes a cipher. If one is not ciphering one letter at a time, but instead chunks of 512 bytes, one could write a cipher that takes the first chunk "regularly" and then adds entropy to each chunk in the subsequent stream based upon the prior chunk. But, not to digress...
  User record {
     userid
     pwhash
     salt
     attributes
  }

 
 

...but while we are on this subject, note that this is even better yet!

User record {
   userid
   pwhash
   salt
   algorithm
   attributes
}

 

Why not keep in a field a note of what algorithm was used the last time the password was reset? This allows for a maintainable system wherein the algorithm used may be swapped out with another one day. Why would you want to upgrade the algorithm used? Because every algorithm will eventually become antiquated. MD5 and SHA1 are types of algorithms for hashing which are no longer considered safe by way of just not being complicated enough. Modern day hackers can break these. Every possible value for a six to twelve alphanumeric string (for example) may be put in a list and used to eventually match a password in an "endless" (not really infinite) series of tries for each item on the list. There is too much complexity in SHA512 today to use this trick to break SHA512 which is encouraged as of this writing, but that won't last forever. Also, breaking the passwords out to their own collection offers a way to keep a history of passwords and force users to not reuse the last few passwords they used.

User record {
   userid
   attributes
}
 
Passwords {
   userid
   pwhash
   salt
   algorithm
   status (active or expired)
   lastUsedTime
}

 

The Zimmerman Telegraph is an example of a cipher fail. During World War I, Germany sent it to Mexico in an attempt to bait Mexico into attacking America. America intercepted the communication and was able to break the code inside. America would end up fighting Germany and not Mexico as things turned out. PGP (Pretty Good Privacy) uses public and private keys to send messages between parties. Any one individual has a both a public (advertised) and a private (secret) key. If Mr. Smith wants to send an encoded message to Mr. Jones then he would use Jones' public key and his own private key in the algorithm. Jones would use Smith's public key and his own public key to decode the message. This is not a typo on my part. Jones never gets handed the private key of Smith. So how could Jones possibly decode Smith's message? I asked about this at the talk and was told that it's just "magic." Somewhere deep inside the mathematics of PGP lives a trick for this. How to manage keys that need to be shared is the great unsolved problem of cryptography. Bankim mentioned that the key for decoding Blu-ray was accidentally published on Intel's web site. Beyond big mistakes like this, one has to assume that such a key would eventually slip out into the public domain anyways. As long as the key for decoding needs to be shared between multiple parties, the key will eventually leak out. Other things I should mention include:
 

• Homomorphic is a concept in which both a blob of text and blob of corresponding ciphertext may be queried for key pieces of information with the SAME means. This is something cryptographers are trying to figure out presently.
• AES stands for Advanced Encryption Standard and it is... a standard.
• Many in cryptography are paranoid the American government has placed "backdoors" in ciphers in the name of spying on companies and individuals.
• Slow algorithms rerun an algorithm over and over again to cipher. To break one of these you'd have to know the increment of reruns.
• Export Control Classification Number (ECCN) is a code for categorizing American exports.
• American laws are lax in the cryptography space. Anyone may use any encryption or no encryption unless they are: giving to parties in another nation, keeping financial data, doing a few key industry-specific things (there are regulations governing Healthcare for example)
• Woodrow Wilson didn't like the Zimmerman Telegraph.