Primer on Symmetric Keys/Session Keys
We previously looked at public key cryptography (PKC), in which we noted that “DLTs would not function with symmetric key algorithms”. Although this is correct, DLTs such as Radix do still make use of symmetric key algorithms for elements of the protocol. This article explores these algorithms and their uses.
Our prior article provided some background to symmetric key algorithms, including looking at some early examples of implementations such as Caesar’s Cipher. One of the more famous examples of cryptography, this cipher used a substitute cipher. This means that the key required to decipher the stored message is the amount of letters in the alphabet that the recipient must add or subtract e.g. if the message was FDW then with a left shift of 3 we could decipher it as CAT.
The idea of the substitute cipher was used for centuries, including during World War II with the Enigma machine. The Enigma relied upon a symmetric key, with the key being a series of settings which changed daily. These settings were sent out to operators; when applied they would allow for messages to be deciphered. Hard to brute force at the time, given the number of potential settings the machine afforded, cracking the Enigma would ultimately prove instrumental to the Allied war effort.
Different types of ciphers
Block and stream ciphers are the two main types of ciphers. Block ciphers encrypt fixed amounts of data (usually 64, 128 and 256 bits) whereas stream ciphers encrypt 1 bit at a time. Stream ciphers are faster and more useful for situations in which the amount of data is continuous, while the more widely used block cipher is used for when the size of the data being encrypted is already known.
There are a number of different types of cipher implementations. Two examples of block ciphers are the Data Encryption Standard (DES) and a subsequently improved version, the Triple DES (3DES). DES was adopted as standard for non-classified information by the United States government in 1977. However, it has subsequently been broken using numerous methods, as Pascol Junod explores. Variants of 3DES, meanwhile, are also now mandated asunfit for usage by the U.S. Department of Commerce.
Filling this gap, a new implementation known as the Advanced Encryption Standard (AES) has now achieved widespread usage. AES uses block sizes of 128 bits, meaning that it can encrypt 128 bits of plain text in each block.
AES also uses three different key lengths (128, 192 and 256 bits). The key lengths refer to the number of bits in a key. All things being equal, the larger the key size the more secure it should be, because it makes brute force attacks more intensive. However, it should be noted that the key lengths of these symmetric keys are not equivalent to their asymmetric implementations which are often much higher (for example, RSA keys are usually 1024-4096 bits long). At the time of writing, a brute force attack against a symmetric 128 bit key or higher should be infeasible given current computing standards.
Block ciphers essentially work by:
- Splitting target text into the fixed length blocks
- Take one of these blocks and use with the key (e.g. 128, 192 or 256 bits for AES) to produce output text
- This process occurs over a number of rounds (e.g. 10 rounds for 128 bit keys), all designed to substitute and mix the input text so that the output is indecipherable. A detailed explanation of how this works can be foundhere
Why are they useful?
As established, PKC allows users to generate a public and private key, with the private key not able to be deduced from the public key. This allows users to give out their public key, without fear of subsequent risk of thefts or unwanted decryptions.
Symmetric keys, in contrast, mean that the key for encryption is the same as decryption. Despite this, symmetric keys are important as they possess advantages of their own over asymmetric implementations. As such, we often use both forms in the same protocol. Notably, symmetric algorithms are simply much faster than their asymmetric equivalents (which as a result are not used to encrypt large amounts of data). As such if we are encrypting a large file we can encrypt the document with a symmetric key using considerably less computing resources than with asymmetric key cryptography. We can then send the encrypted document to the recipient along with the symmetric key which they can then use to decrypt the file.
To avoid this key being used again by the party we are sending to (or anyone else), we can use what is known as a session key. These session keys are symmetric keys which, as the name suggests, are only used for a single session. These symmetric session keys can then be encrypted using an asymmetric key (by using the recipient’s public key) so that only the intended target can decrypt the session key – preventing unwanted interception of the document or file.
To ensure that they can only be used by the intended recipient, we can generate them by combining the sender’s private key with the recipient’s public key. This means that if Alice wants to send a session key to Bob, she can combine her private key with Bob’s public key in order to create a shared combined key which only Bob will know to decrypt (as only he will know the public key).
How they are used in Radix
Symmetric key algorithms are not currently used by the Radix Ledger core.
Client access to the Radix API is HTTPS enabled, and this requires key-exchange algorithms and symmetric ciphers described above in order to facilitate secure communications. Note that all HTTPS-enabled web sites use some form of key-exchange and symmetric-key cipher to facilitate secure communications. The exact algorithms used are negotiated between client and server as part of the underlying communications protocol.
The Radix Java client libraries provide facilities for encrypting data using AES for storage. The most common use for this is for storage of encrypted private key data.