1
$\begingroup$

I was wondering if we take just 256 bits of plain text and simply XOR every bit with a 256 bit key, how strong can it be ?

| improve this question | | | | |
$\endgroup$
6
$\begingroup$

That construction is called a one-time pad or OTP (not to be confused with a one-time password). OTP's are theoretically perfectly secure as long as the key is not repeated or reused and the key is indistinguishable from random by any adversary. In that case any 256 bit plaintext message is equally likely, so it is impossible to even brute force the key. Because of that, the size of the key and plaintext do not even matter, as long as there are as many bits for the key as there are bits in the plaintext.

Note that an OTP does not provide message integrity nor authenticity, only confidentiality. Of course the exact size of the input is leaked by an OTP too, so that's not kept secure either.

Of course, generally the practical security depends on the system, the quality of the randomness, the actual access to the key etc. etc. etc.

| improve this answer | | | | |
$\endgroup$
  • $\begingroup$ Thankyou very much, for your answer!!! But can you please explain it to me, why practical algorithms like AES use so much of processes along with XORing of the keys for security ??? $\endgroup$ – Vivekanand V Nov 30 '19 at 18:20
  • 3
    $\begingroup$ AES can be used for multiple messages with any size (when used with the correct mode of operation). Smaller sized keys can also be generated by key derivation and such, which is not possible for one-time pads. AES may take some processing power, but must systems perform it fast enough to even saturate a network connection or even encrypt / decrypt data on a modern SSD - although hardware acceleration is usually required for full speed operation. $\endgroup$ – Maarten Bodewes Nov 30 '19 at 18:41
  • 1
    $\begingroup$ "Of course, generally the practical security depends on the system, the quality of the randomness, the actual access to the key etc. etc. etc. " - the OTP is the Carnot engine of cryptography :) $\endgroup$ – The_Sympathizer Dec 1 '19 at 3:51
  • 1
    $\begingroup$ No, that's key reuse, then the result is absolutely insecure. Your key would be known if the attacker knows just a single block of plaintext (see many-time pad attack) Just use a secure cipher please. E.g. AES in CTR mode would be a good idea or a fast stream cipher. $\endgroup$ – Maarten Bodewes Dec 3 '19 at 22:16
  • 1
    $\begingroup$ That one is easy: the design of Rijndael (the cipher which got promoted to AES of course). $\endgroup$ – Maarten Bodewes Dec 3 '19 at 22:43
3
$\begingroup$

As long as the key is perfectly random and you only use it once, the scheme is perfectly secure.

The problem is that whole "you only use it once" bit. If you use the key more than once then the attacker can xor the ciphertexts to obtain the xor of the plaintexts. Since most messages are far from random, statistical analysis techniques can often reveal a lot of information given an XOR of plaintexts.

| improve this answer | | | | |
$\endgroup$
1
$\begingroup$

This is perfectly secure (one time pad) as long as the key remains secret and is used only once but not very practical. The problem is that instead of a safe channel for transmissing the message you will now need a safe channel for transmitting the key, or be limited in the total length of messages a recipient can decode before both sender and recipient run out of key.

In practice, many public key encryption protocols actually work with a one time key used for one transmission (the "session key") that is generated for the sake of the session and transmitted using the public key encryption method. So one (or rather several) time pad methods are actually used in public key encryption for efficiency reasons, with the principal long-term protection of the public key encryption system only covering the sharing of a common symmetric key for a single session.

| improve this answer | | | | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.