Cryptanalysis 2 (by alaric)

In a previous post, I discussed the analysis of an initially robust-looking combination of S-boxes, then suggested two potential extensions of the algorithm to examine.

Read more »

Cryptanalysis (by alaric)

Cryptanalysis is the science/art of analysing an encryption system's design to try and figure out how you'd break it.

If encryption systems were used properly, this would be very hard. After all, in that case, all you'd ever have access to was the design of the encryption system and a stream of intercepted encrypted messages.

However, in practice, it's possible to guess parts of the messages (perhaps most start with "Dear ..."), or even to occasionally steal a decrypted message and pair it up with its encrypted version, then study the relationships between them (known plaintext attacks). Or sneak a spy into the organisation being studied, and just ask them to send emails to the person at the other end of the encrypted link, in the middle of the night, at agreed times, so it's easy to spot the encrypted version of the message. Then you have a chosen plaintext attack, which is the most powerful kind.

Read more »

Splay trees, compression, encryption, and embedding (by alaric)

There's a little-known data structure with some useful properties; the Splay tree.

It's quite a useful data structure in its own right, but it also has interesting applications in data compression, and cryptography...

Read more »

Avalanche functions (by alaric)

One way of looking at the design of a cipher is that you are taking a small fixed-block-size cipher of known good design, and finding a way to extend the security of that small block cipher to a larger block, potentially variable sized.

For example, stream ciphers (and their close cousins, 'cipher modes' like OFB, CFB, and so on) work by splitting the message into smaller blocks and applying the mini-cipher to each block in turn; but if they did that with the same key each time, the result would not be particularly secure for various reasons - weaker than the mini-cipher - so they use various means of causing interrelationships between the mini-blocks.

This brings about a property known as "avalanche"; namely, changing a single bit of the input should cause 'cascading changes' such that (on average) half of the output bits are changed, meaning that the new output is as related to the old output as two independently chosen random bit strings.

ARGON cryptography (by alaric)

I thought I'd like to discuss the design decisions behind the rather brief description of the "security levels" mentioned on the MERCURY page. Don't worry, you don't need to go and read it first - I'll duplicate everything in this post.

To summarise, my design requirement was to implement a cryptograhic architecture for both communications and storage of sensitive data, which allows for:

1. Both parties in a communication may have differing security requirements; the maximum of both need to be met
2. Security levels need to be specified in a way that is future proof; eg, DES would have been unbreakable in World War II, but nowadays it should only be considered suitable for relatively unimportant data
3. Physical communications links may have a certain element of external protection, rendering encryption an unnecessary burden; a cluster of servers locked in a highly screened server room together should be able to communicate sensitive data between each other in the clear, or with a fast lightweight encryption algorithm - after all, an assailant in the room with them could easily interfere with the machines themselves to get them to divulge their keys. However, the same information being shared across the public Internet would need heavy encryption, or be banned altogether.

4. Communications links and data storage devices might have a maximum security level of information they can be trusted to at all, no matter how heavily encrypted it is, because any crypto algorithm is potentially breakable.

   Read more »