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 (subscriber, #313) [Link]
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]
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]
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds