The patterns paradigm has arisen in the object oriented world to document those coding tasks that seem to repeat frequently enough to need common names and common architectures. Patterns, once documented, assist communication, and provide shortcuts to existing code.Abstract: Cryptographic coding is a small subset of coding. It includes many tasks of a very varied nature, in part because the demands of the higher level application are so varied, and so divergent from the nature of cryptography. Yet, patterns emerge.
This draft note is a first cut attempt to list those patterns, with some brief explanation of each.
The patterns approach places the result at the top of the mental heap. It remains to the designer to select from the patterns in order to construct his design. This is a bottom-up, toolbox approach, not a top-down approach.
Necessarily, there won't be a pattern for all needs. And, patterns will rarely be totally adequate for a fully done security model, as for almost all security requirements, there are too many foibles to neatly match the coding done by others.
Yet, fully created security models are generally too expensive. They are rarely done, and when done, they are often not done completely or properly.
The real world of coding is more full of hacked-in tools from a grab bag than security modelists would like to thing. This present document attempts to add some discipline to the ad hoc toolbox, accepting the status quo that most security programming is done by those who are not able to do full security modelling (whether by reasons of expense or of knowledge).
There are approximately two popular patterns for protecting connections: the PKI model and the Opportunistic model. These are best described by their champion applications, SSL and SSH respectively.
Both of these models solve the core problem of such protocols - how to share a secret key. Once they have shared the secret key, these protocols are almost identical. For this reason, we break up the patterns into a shared secret connection pattern, and secret key sharing patterns.
Document TLS's method here...
Is there enough merit / popularity in a packet oriented protocol?
The task of sharing a secret key is an important one. It is the keystone on which many other patterns rely. Its importance is such that it merits an entire set of patterns, even though the job remains only half completed once the key is shared.
There is an important null pattern for key sharing which should always be listed as case zero. This is simply having the users or the higher layer application share the key. This is more than a theoretical case; many systems should consider including the method as a fall-back, a temporary or a baseline cheapest method.
The clumsiness and simplicity of manual sharing of the key leads to all sorts of difficulties that might or might not be tractable, so there are many more sophisticated methods. Those are the remainder of the patterns. But, each of these patterns come with costs and weaknesses that may for a given application not give any benefit over the null pattern.
The null case of user key sharing follows these steps.
Generate a random string of bytes as the key.
Convert this string into hexadecimal notation.
Print out the hexadecimal form of the string in groups of two or four characters. For example, here is a group from OpenPGP:
64F7 F362 9591 4402 0252 DB5C 8674 8ABC F72E FEA5
Have Alice read out the character groups to Bob. To assist in reading the letters, use the phonetic alphabet: Alpha, Bravo, Charlie, Delta, Echo, Foxtrot.
Importantly, this should be done over any means of communication other than the one that the later application uses. For example, if the net is used for email, have Alice phone up Bob on her cellular/mobile phone to read over the shared key.
Bob enters them into his application, and initiates the next step (whatever it is: comms link, decrypt a file).
The security of this method is mostly dependent on these paramaters:
How long is the string of bytes? A string of bytes that is a 32 bit quantity (4 characters in hexidecimal) is easily crunchable by a machine. Yet a string that is not easily crunchable, say 128 bits (16 characters) may be too unweildly for the application.
Is the attacher plausibly listening to the transfer of the secret key, and can he do anything about it?
In general, user key sharing is used in these areas:
Where no better method exists. This would often be where the software had not been written to use public key methods, perhaps because of cost, or speed / space constraints (low powered devices).
Where a better method is being produced, but it will be a while before it is fully complete. This is quite viable for getting a product out the door to a small group of users. Showing off the rest of the application with a weaker security model in place is no problem if attacks don't start until some threshold of users is reached. Time to market is generally critical, and too much security is a common product killer.
Where the better method exists, but it is too expensive for some applications.
The canny reader will see that the above is quite similar to sharing passwords. But, this is not a recommended pattern.
Passwords are generally chosen to be a human memorable string. For this reason, they generally relate to one or a small group of people. And they generally relate to an environment where the sharing of the password does not face difficulties of text forms.
If there is no need to repeat this exchange of secret keys, Ephemeral Diffie-Hellman key exchange (EDH) makes for a good mechanism.
The parties generate some shared paramaters.
Each party generates a big random number from
They swap their numbers.
Each party then individually completes by ...
This method generates a key which can be used once. It is useful for casual encryption, where the
Opportunistic Public Key Exchange is the SSH method. In this method, Alice generates a public key, and sends it to Bob. Bob generates a random number as a key, encrypts it with the public key, and sends it back to Alice. Alice
This is the domain of the x.509 certificate regime known as PKI. It is primarily in use with the TLS and SSL family of protocols.
Document protection models take into account that the node where the documents rest is also a risk. In practice, there is plenty of empirical evidence to suggest that documents are almost only at risk while at rest on a node: hacking, email interception, spyware are all breaches of the operating system and readings of the documents on the user's computer.
There are two general modes here: documents that are in motion from person to person, and ones at rest. Obviously, documents in one of these modes will also enter the other mode, but the patterns tend to seperate across those lines.
Moving a document from a person to a person implies these things: the document passes across a variety of untrusted nodes in a manner that is substantially outside control (so a communications protection pattern cannot be used) and the document is equally at risk or more so when it rests on the destination node.
P2P crypto patterns are end-to-end, and also capable of remaining protected at the end. These modes support primarily email and chat/IM.
The OpenPGP model is by far the most successful method of protecting documents in motion.
describe...
User Alice generates public key pair.
Alice sends public key to Bob, sender of messages.
Bob encrypts document to Alice's public key, using public key packet pattern.
Bob sends document to Alice,
Connection oriented patterns do not help as the document lacks protection on the node. For example, START/TLS is a mediocre pattern, as are designs that use TLS/SSL to protect chat/IM traffic.
When documents are at rest, on a node, the emphasis shifts to breadth and efficiency of protection. Can a method protect a directory or folder? A file system? And do so when exposing one file at at time? Without incurring overhead?
File system protections.