Re: pgcrypto: Remove internal padding implementation
От | Peter Eisentraut |
---|---|
Тема | Re: pgcrypto: Remove internal padding implementation |
Дата | |
Msg-id | 241e48c9-7dc9-2365-fcf1-9d4876692d62@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pgcrypto: Remove internal padding implementation (Jacob Champion <pchampion@vmware.com>) |
Ответы |
Re: pgcrypto: Remove internal padding implementation
|
Список | pgsql-hackers |
>> Interesting. I have added test cases about this. Could you describe >> how you arrived at the second test case? > > Sure -- that second ciphertext is the result of running > > SELECT encrypt_iv('abcdefghijklmnopqrstuvwxyz', '0123456', 'abcd', 'aes'); > > and then incrementing the last byte of the first block (i.e. the 16th > byte) to corrupt the padding in the last block. I have added this information to the test file. >> Is there any reasonable meaning of the previous behaviors? > > I definitely don't think the previous behavior was reasonable. It's > possible that someone built a strange system on top of that > unreasonable behavior, but I hope not. > >> Does bad padding even give correct answers on decryption? > > No -- or rather, I'm not really sure how to define "correct answer" for > garbage input. I especially don't like that two different ciphertexts > can silently decrypt to the same plaintext. > >> What does encryption without padding even do on incorrect input sizes? > > Looks like it's being silently zero-padded by the previous code, which > doesn't seem very helpful to me. The documentation says "data must be > multiple of cipher block size" for the pad:none case, though I suppose > it doesn't say what happens if you ignore the "must". Right, the previous behaviors were clearly faulty. I have updated the commit message to call out the behavior change more clearly. This patch is now complete from my perspective.
Вложения
В списке pgsql-hackers по дате отправления: