Weekly edition Kernel Security Distributions Contact Us Search Archives Calendar Subscribe Write for LWN LWN.net FAQ Sponsors

# An idea: If one does it, then one Should at Least try to do it Well

## An idea: If one does it, then one Should at Least try to do it Well

Posted Aug 12, 2013 9:46 UTC (Mon) by martin_vahi (guest, #92302)
In reply to: Web-(developer)-oriented Crypto Algorithm by rmayr
Parent article: Gräßlin: FLOSS after Prism: Privacy by Default

The short answer is: TXOR and one-time pad are symmetric-key algorithms and therefore do not address the scenario that You described.

The motivation for rejecting public-key cryptography, regardless of crypto algorithm, is as follows:

Claim_1)

ciphertext=encryption(part_1_of_the_keypair,cleartext)=function_1(cleartext) cleartext=decryption(part_2_of_the_keypair,ciphertext)=function_2(ciphertext)

That is to say:

cleartext=function_2(ciphertext) cleartext=function_2(function_1(cleartext))

id est

There is a bijection between cleartext and ciphertext and the function_2 is an inverse function of the function_1.

Claim_2)

In the case of all public key cryptography algorithms, one of the parts of the key pair is public. As the encryption/decryption algorithm is also public, one of the functions, function_1 or function_2 is always public.

It is only a matter of mathematical skill, how to construct function_1 or function_2, if it is firmly known that the publicly known function definitely has a reverse function.

Claim_3)

The fact that I'm dumb enough to fail the task, does not mean that others, professional mathematicians, who work on it as part of their day-job, may-be, but not only, in the NSA, can't solve it.

An idea: If one does it, then one Should at Least try to do it Well

Posted Aug 12, 2013 10:10 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

you seem to be missing the reason that public key algorithms have been used, namely the difficulty in distributing and managing symmetric-key algorithms (including one-time-pads)

public key algorithms work when function1 and function2 are both well known, but it is impractical to derive one key when you know the other. If you are not willing to trust that, it's trivial today to use symmetric keys (if you solve the key distribution problem)

An idea: If one does it, then one Should at Least try to do it Well

Posted Aug 12, 2013 10:23 UTC (Mon) by rmayr (subscriber, #16880) [Link]

I understand the difference between symmetric and asymmetric cryptography, and that is the reason for my question. OTR is the most difficult option in terms of key management. Not only do you need to keep the key secret during the exchange between involved parties (in contrast to asymmetric crypto), but is also going to have to be as long as the message itself, and must never be re-used again.

That is what confuses me: you are talking about web programming as the application area for your character-based OTR combination operator, but in web programming I see no way on how to realistically do the key management for anything remotely OTR-like (hence most/all claims of OTR for web applications are snake oil).

If you intend to reject asymmetric crypto, then I'd love to hear a better option for it (as we have known for quite a while that e.g. DH and RSA will be susceptible to quantum algorithms once we get a sufficient number of qbits in a stable configuration).

Btw, asymmetric crypto is not inherently less secure than symmetric crypto, as the decryption operation is always the inverse of encryption (we are talking about lossless encryption, I assume ;-) ). It has just been studied a lot longer.

Rene

An idea: If one does it, then one Should at Least try to do it Well

Posted Aug 12, 2013 10:24 UTC (Mon) by rmayr (subscriber, #16880) [Link]

To clarify my btw, symmetric crypto has been studied for a lot longer than asymmetric. My original comment might be read the other way, sorry about that.