Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Most plaintext must be fed as a string or a binary object to be encrypted. However, it's often possible to mis-decode the plaintext before encrypting it.

i.e. If it's received as a string in JSON, you often don't know if the string is an encoded representation (e.g. plain, hex encoded, base64 encoded, etc)

Example:

If the message to encrypt is received as 48656c6c6f (which is Hello in hexadecimal encoding), it's possible to accidentally encrypt 48656c6c6f instead of Hello.

When you decrypt, you'll get back whatever you started with, so it's easy to never know you are encrypting incorrectly.

This results in a plaintext input where the variation per-byte is very small. If you accidentally encrypt 01001000 as an 8-byte string instead of a single byte (0x48, H), then each resulting ciphertext byte is the result of only one of two inputs: 0 or 1.

Question:

  • Is it insecure to make this mistake?

  • Is the ciphertext somehow easier to break because you used the wrong plaintext?

  • What if you make this same mistake with the key instead of the plaintext?

Example Ruby code:

require 'openssl'

=begin

Most plaintext must be fed as a string or a binary object to be encrypted.
However, it's often possible to mis-decode the plaintext before encrypting it.

i.e. If it's received as a string in JSON, you often don't know if the string
is an encoded representation (e.g. plain, hex encoded, base64 encoded, etc)

Example:
If the message to encrypt is received as "48656c6c6f" (which is "Hello" in hex),
it's possible to accidentally encrypt "48656c6c6f" instead of "Hello".

When you decrypt, you'll get back whatever you started with, so it's easy to
never know you are encrypting incorrectly.

This results in a plaintext input where the variation per-byte is very small.
If you accidentally encrypt "01001000" as an 8-byte string instead of a single
byte (0x48, 'H'), then each resulting ciphertext byte is the result of only
one of two inputs: '0' or '1'.

Question:

* Is it INSECURE to make this mistake?
* Is the ciphertext somehow easier to break because you used the wrong plaintext?
* What if you make this same mistake with the KEY instead of the plaintext?

=end

real_plaintext = "Hello" # 5 bytes
plaintext_1 = real_plaintext.unpack('H*').first
puts plaintext_1 # 48 65 6c 6c 6f
plaintext_2 = real_plaintext.unpack('B*').first
puts plaintext_2 # 01001000 01100101 01101100 01101100 01101111
plaintext_3 = [real_plaintext].pack('m')
puts plaintext_3 # SGVsbG8=

# Stream cipher used here to make it more obvious about
# the different resulting lengths
def encrypt(str, method='aes-256-ctr')
cipher = OpenSSL::Cipher::Cipher.new(method)
cipher.encrypt
key = cipher.key = cipher.random_key
iv = cipher.iv = cipher.random_iv
cipher.update(str) + cipher.final
end

puts "Result of real_plaintext:"
result = encrypt(real_plaintext)
puts "Len: #{result.length} - #{result.unpack('H*').first}"

puts "Result of plaintext_1:"
result = encrypt(plaintext_1)
puts "Len: #{result.length} - #{result.unpack('H*').first}"

puts "Result of plaintext_2:"
result = encrypt(plaintext_2)
puts "Len: #{result.length} - #{result.unpack('H*').first}"

puts "Result of plaintext_3:"
result = encrypt(plaintext_3)
puts "Len: #{result.length} - #{result.unpack('H*').first}"
share|improve this question
1  
I think you are confusing security with what is a blatant bug. –  Jeff-Inventor ChromeOS Aug 8 at 3:50

1 Answer 1

As long as you're using any modern encryption algorithm (and you're using it correctly: random key, new random or unique IVs for each message, depending on the mode of operation, etc.) then you'll be fine. In fact, you'd be fine even if an attacker got to choose which plaintext you encrypted and got to see the result; this information would not help him decrypt other ciphertexts. (This is a chosen-plaintext attack, and any standard encryption algorithm can withstand one. Unless you consider ECB a standard encryption algorithm. Don't use ECB.)

There is, however, a possible exception to this rule that might relate to your third question. If you accidentally encrypt a plaintext that includes your encryption key, then in theory this could lead to problems. At least, one could no longer prove the system's security under standard assumptions about the blockcipher.

If your third point was asking "What if I use the wrong key?" then, yes, this is a problem. They key you accidentally use might be brute-forcible. For example, a 128-bit AES key consisting of 16 ASCII hex characters (0-9, A-F) permits only $16^{16} = (2^4)^{16} = 2^{64}$ possible keys.

share|improve this answer
    
If he used the wrong key then he wouldn't be able to decrypt it, and that would be detected via integrity checks. If you happen to encrypt your key with modern standard algorithms wouldn't your logic from the first paragraph still hold true? –  raz Aug 7 at 18:39
    
@raz I don't know what you include in "modern algorithms" but I would not say that all "modern ciphers" (or, more precisely, modes of operation that use a cipher) contain integrity validation. –  owlstead Aug 7 at 21:28
    
That's true. I was misleading in saying algorithms when I should have said protocols. But the question didn't address protocols. –  raz Aug 7 at 23:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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