Asymmetric cryptography – Plaintext size error
Question:
I’m trying to encrypt small data using asymmetric cryptography with python. I’m currently using M2Crypto to generate 1024 bit private/public key pair.
After using different python libraries, such has M2Crypto and Pycrypto (with several variations on it), I’m having plaintext size problems: ValueError: Plaintext is too long.
This happens because I’m trying to encrypt the data and after that encrypting that last encryption (encryption over encryption), e.g.:
Encryption:
EKpuuser(EKprown(Data)) -> EData
puser: Public key user,
prown: Private key (data) owner
Decryption:
DKpruser(DKpuown(EData)) -> Data
pruser: Private key user,
puown: Public key (data) owner
I have tried many solutions that I’ve found around the web, but the only one that helped me to pass this problem was using signatures before doing encryption:
ciphertext = 'xpto'
m_EOi = hashlib.sha1()
m_EOi.update(ciphertext_EOi)
sig_EOi = (m_EOi.hexdigest())
But this solution isn’t what I need, because after I used it and encrypt the signature (and encrypt the encryption), then do the decryption, can’t decrypt the signature, so I can’t get to the initial message.
Edited:
I already have done something like e.g.:
BLOCK_SIZE = 32
PADDING = '{'
message = 'today'
key = 'aaaaaaaaaa123456'
pad = lambda s: s + (BLOCK_SIZE - len(s) % BLOCK_SIZE) * PADDING
EncodeAES = lambda c, s: base64.b64encode(c.encrypt(pad(s))) cipher = AES.new(key)
encoded = EncodeAES(cipher, message)
key = 123
h1 = SHA256.new()
h1.update(key)
key1 = h1.digest()[0:16]
iv1 = Random.new().read(16)
cipher1 = AES.new(key1, AES.MODE_CFB, iv1)
criptogram1 = iv1 + cipher1.encrypt(data1)
But I allways have the plaintext size problem.
Answers:
Asymmetric cryptography isn’t made for what you are trying to do. Asymmetric cryptography is usually used in hybrid solutions to encrypt the keys of symmetric cryptographic systems which are used to encrypt the actual data.
Usually something like this:
data + a symmetric (random) key (K) -> symmetric cipher (e.g. AES) -> cipher text
K + public asymmetric key of the recipient -> asymmetric cipher -> Ke
Then you transmit the cipher text and Ke to the recipient
K is usually way smaller than the maximum data size of asymmetric ciphers while your ordinary plain text data is not.
When you encrypt data with an RSA key, for example, you want to pad the data with OAEP padding. No matter how small your plaintext is, like “Today”, it’s going to get padded out to the full modulus of the key, e.g. 1024 bits. If you next try to encrypt that with the same size key, it won’t fit. There is no room anymore to pad again. You need a bigger key, or, you don’t pad. Not padding would be a big mistake — you need the padding to be secure.
Why would you encrypt twice anyway? It’s not making it any safer. Are you devising your own scheme? That would be risky.
Why would you sign ciphertext? A digital signature over ciphertext is signing a document of unintelligible gibberish — try taking that signature in front of a court. Why not just add a MAC?
After more research I’ve managed to find something that helped me. It isn’t 100% what I was looking for (related to the plaintext size error) but helps me in a way that I use signatures the go around the problem. Here is the link were I did find out the information:
I’m trying to encrypt small data using asymmetric cryptography with python. I’m currently using M2Crypto to generate 1024 bit private/public key pair.
After using different python libraries, such has M2Crypto and Pycrypto (with several variations on it), I’m having plaintext size problems: ValueError: Plaintext is too long.
This happens because I’m trying to encrypt the data and after that encrypting that last encryption (encryption over encryption), e.g.:
Encryption:
EKpuuser(EKprown(Data)) -> EData
puser: Public key user,
prown: Private key (data) owner
Decryption:
DKpruser(DKpuown(EData)) -> Data
pruser: Private key user,
puown: Public key (data) owner
I have tried many solutions that I’ve found around the web, but the only one that helped me to pass this problem was using signatures before doing encryption:
ciphertext = 'xpto'
m_EOi = hashlib.sha1()
m_EOi.update(ciphertext_EOi)
sig_EOi = (m_EOi.hexdigest())
But this solution isn’t what I need, because after I used it and encrypt the signature (and encrypt the encryption), then do the decryption, can’t decrypt the signature, so I can’t get to the initial message.
Edited:
I already have done something like e.g.:
BLOCK_SIZE = 32
PADDING = '{'
message = 'today'
key = 'aaaaaaaaaa123456'
pad = lambda s: s + (BLOCK_SIZE - len(s) % BLOCK_SIZE) * PADDING
EncodeAES = lambda c, s: base64.b64encode(c.encrypt(pad(s))) cipher = AES.new(key)
encoded = EncodeAES(cipher, message)
key = 123
h1 = SHA256.new()
h1.update(key)
key1 = h1.digest()[0:16]
iv1 = Random.new().read(16)
cipher1 = AES.new(key1, AES.MODE_CFB, iv1)
criptogram1 = iv1 + cipher1.encrypt(data1)
But I allways have the plaintext size problem.
Asymmetric cryptography isn’t made for what you are trying to do. Asymmetric cryptography is usually used in hybrid solutions to encrypt the keys of symmetric cryptographic systems which are used to encrypt the actual data.
Usually something like this:
data + a symmetric (random) key (K) -> symmetric cipher (e.g. AES) -> cipher text
K + public asymmetric key of the recipient -> asymmetric cipher -> Ke
Then you transmit the cipher text and Ke to the recipient
K is usually way smaller than the maximum data size of asymmetric ciphers while your ordinary plain text data is not.
When you encrypt data with an RSA key, for example, you want to pad the data with OAEP padding. No matter how small your plaintext is, like “Today”, it’s going to get padded out to the full modulus of the key, e.g. 1024 bits. If you next try to encrypt that with the same size key, it won’t fit. There is no room anymore to pad again. You need a bigger key, or, you don’t pad. Not padding would be a big mistake — you need the padding to be secure.
Why would you encrypt twice anyway? It’s not making it any safer. Are you devising your own scheme? That would be risky.
Why would you sign ciphertext? A digital signature over ciphertext is signing a document of unintelligible gibberish — try taking that signature in front of a court. Why not just add a MAC?
After more research I’ve managed to find something that helped me. It isn’t 100% what I was looking for (related to the plaintext size error) but helps me in a way that I use signatures the go around the problem. Here is the link were I did find out the information: