Software Development : Security : Cryptography

From bitrary
Jump to: navigation, search

Software Development : Security

Wikipedia entry

Most of the details about cryptography can be read from various other sources that are often better than I,, can ever write. However, this chapter exists to offer a few lines of thought in a different style than they are available from elsewhere.

Public key Cryptography

Why Public key Cryptography is Fundamentally Flawed

It is a fact that a decryption result must match with an encrypted cleartext.

$cryptotext = encrypt(cleartext)$

$decryptionresult = decrypt(cryptotext)$

$decryptionresult = cleartext$

$encrypt^{-1} = decrypt$

i.e. encryption function is an inverse function of decryption function.

$encrypt(cleartext) = encryptionalgorithm(encryptionkey,cleartext)$

$decrypt(cryptotext) = decryptionalgorithm(decryptionkey,cryptotext)$

The public key cryptography is fundamentally flawed due to the fact that at least one of the functions, $encrypt$ or $decrypt$, is publicly known, e.g. known to all attackers and it's only a matter of mathematical ingenuity of the attackers to construct the inverse function of the publicly known function.

Consequently, all of the https and web certification based approaches, including the ones used by the Tor Project, are fundamentally flawed, broken. However, if the key-pair is used as a single private key, then public key encryption algorithms can be used as symmetric key encryption algorithms. (Test Data)

Occurrences in Practice

What to do, when the Public key Cryptography is the only Option

If it is mathematically guaranteed that it takes $t_{break}$ seconds to break key $K$ of public key cryptography algorithm $Alg$ and the key negotiation (Diffie-Hellman, etc.) time $t_{nego}$ is considerably shorter than the $t_{break}$, id est $t_{nego} \lt t_{break}$, then a secure time-period $t_{secure}$ can be created by negotiating $key_1$, then using the $key_1$ for creating a temporarily secure channel and within that channel negotiate $key_2$ and then within that same channel, id est while encrypting everything with the $key_1$, create a new secure channel with the $key_2$. The channel created with the $key_2$, which resides in the channel created with the $key_1$, id est onion-encrypted channel, is then used for negotiating $key_3$, etc. In the end there will be onion-encryption that uses about 100 public encryption keys, may be thousands of keys. A thing to keep in mind is that the $t_{break}$ depends on the computing resources available to the NSA-and-alike and usually they have far more computers than any freedom fighters have. The Empire is heavy.

A few Public key Cryptography Related Observations

As explained in the previous section, the public key cryptography is fundamentally flawed, but due to its wide use it is still useful to know some of the methods and observations that are related to it.

Man in the Middle Attack

Often the public keys of the public key cryptography are exchanged in a non-secure channel by using some key-exchange algorithm like the Diffie-Hellman key exchange algorithm. (To be continued.)

Ideas for Possible Countermeasures

The classical solution is the quantum key distribution, but may be a solution to study might be based on an idea that one side generates its private key based on the secure hash of the private key of the other and the key exchange has a time limit that the "man in the middle" is not able to meet due to lack of computing power and due to the fact that the speed of light guarantees that it takes too long for the eavesdropper to send the signal to its distant, huge, data centers for fast cracking. Greater distances might be covered by using multiple, short, hops like it is done in the Tor network. May be even the Diffie-Helleman key exchange might be strengthened by using that extra measure.

The One-time pad

...has its own chapter


...has its own chapter

Things to Look out for

"Semantic Security"

Ciphertext Repetition as Metadata

The ciphertexts of the one-time-pad vary even, if they all encode a common cleartext. For other ciphers that might not be the case. Therefore, data must always be accompanied with some pseudo-random data to introduce ciphertext variation.

Ciphertext Length as Metadata

If the enemy knows that the clear-text can consist of only 2 values, strings "yes" and "no", then they can guess the clear-text value by looking at the ciphertext length, without analyzing anything else. If a random "blob" consists of 3 characters, then, no matter what the characters are, the cleartext is "yes". If the random "blob" consists of 2 characters, then, no matter what the characters are, the cleartext is "no". That kind of situation might occur with control applications, where robots are controlled through encrypted commands. The "letter" length as metadata might even give hints for human communication.

The analysis might be inspired by the parsers of context dependent grammars. Variation of lengths in the time series of encrypted commands might provide the context.

Ciphertext Time Series as Metadata

If You want to smuggle something out of a corporate network by sending it out in an encrypted form, then, do not do it during a time, when the rest of the traffic is low and Your traffic forms most of the traffic. That peaks at logs and catches network administrators, probably auto-guards, attention, sets off an alarm.

In the case of Your own network the time series of non-hostile traffic can give glues to enemies. In a military context, if the ether is quiet and suddenly there exists loads of encrypted communication, then that can reveal some information to attackers. An anti-measure might be to add a flag to text based data containers (JSON, XML, ProgFTE, etc.) to indicate, whether the container contains junk or real data. If the data rate is constant, data is sent continuously, then it's not possible to figure out, if real data flows or is it junk that is being sent.

Shoddy Random Number Generators

There is a rumor that sometimes the standard random generators are so bad that their output ends up being on some "high dimensional" (how high is high?) hyperplane.

Real-time Clock Related Problems

Future D-day Attacks

Attackers know from the past:

    s_auth_1=hash(password.timestamp(a second in 1984))
    s_auth_2=hash(password.timestamp(a second in 1985))
    s_auth_3=hash(password.timestamp(a second in 1986))

For some future D-day the s_auth might be calculated in advance and with enough planning and luck there might be ample time for, if not cracking the password, then figuring out the hash value. The antimeasure might be to replace the timestamp based system with a challenge-response based system, where the communication for the challenge-response exchange is encrypted. The random challenge must be generated realtime, not saved in advance.