block-based cipher padding
Locked
 
|
Hi Chris, I’ve finally figured out what was going wrong with
some of my CBC tests. I have some more questions about padding. The test: Case
#3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key Key
: 0x6c3ea0477630ce21a2ce334aa746c2cd IV
: 0xc782dc4c098c66cbd9cd27d825682c81 Plaintext
: This is a 48-byte message (exactly 3 AES blocks) Ciphertext:
0xd0a02b3836451753d493665d33f0e886 2dea54cdb293abc7506939276772f8d5 021c19216bad525c8579695d83ba2684 Is returning the value: 'D0A02B3836451753D493665D33F0E8862DEA54CDB293ABC7506939276772F8D5021C19216BAD525C8579695D83BA2684D248B3E0F2388C137102846EB06272FF'
which is correct except for the padding. Since we are using the padding
and it will be removed in our system should this be considered a passing test? My guess is yes but if we send these encrypted values to
other systems will they know how to un-pad and decrypt the cipherText? In
other words, how widely adopted is Schneier’s and Ron Teitelbaum President / Principal Software Developer US Medical Record Specialists Squeak Cryptography Team Leader _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
Hi Ron,
To communicate with with external systems you will have to know the exact padding scheme they use. Different systems may use different padding schemes so it may be a good idea to factor our padding behavior into some sort of pluggable scheme so we can accomodate varying systems more easily. I implemented scheme #2 on page 68 of "Practical Cryptography". It is very simple and I believe I implemented it correctly (test case), so the difference in the test results is probably due to your test using a different padding scheme. In that section of the book the authors say, "Either padding scheme works just fine. There are no cryptographic ramifications to padding. Any padding scheme is acceptable, as long as it is reversible. The two we gave are just the simplest ones." Simple is nice. We can't turn off padding (although streaming modes like the suggested CTR mode don't need it), but pluggable padding schemes seems like a fine solution to me. Try to keep it simple! :) Regards, Chris --- Ron Teitelbaum <[hidden email]> wrote: > Hi Chris, > > > > I've finally figured out what was going wrong with some of my CBC > tests. I > have some more questions about padding. > > > > The test: > > > > Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC > with > 128-bit key > > Key : 0x6c3ea0477630ce21a2ce334aa746c2cd > > IV : 0xc782dc4c098c66cbd9cd27d825682c81 > > Plaintext : This is a 48-byte message (exactly 3 AES > blocks) > > Ciphertext: 0xd0a02b3836451753d493665d33f0e886 > > 2dea54cdb293abc7506939276772f8d5 > > 021c19216bad525c8579695d83ba2684 > > > > Is returning the value: > > D525C8579695D83BA2684D248B3E0F2388C137102846EB06272FF' which is > correct > except for the padding. Since we are using the padding and it will > be > removed in our system should this be considered a passing test? > > > > My guess is yes but if we send these encrypted values to other > systems will > they know how to un-pad and decrypt the cipherText? In other words, > how > widely adopted is Schneier's and Ferguson's padding suggestion? > Should we > enable a switch to allow developers to turn this off? > > > > Ron Teitelbaum > > President / Principal Software Developer > > US Medical Record Specialists > > [hidden email] > > Squeak Cryptography Team Leader > > _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
RE: Re: block-based cipher padding
|
|
> From: Chris Muller
> Sent: Monday, July 10, 2006 10:30 PM > > Hi Ron, > > To communicate with with external systems you will have to know the > exact padding scheme they use. Different systems may use different > padding schemes so it may be a good idea to factor our padding behavior > into some sort of pluggable scheme so we can accomodate varying systems > more easily. Sounds like a good idea. > > I implemented scheme #2 on page 68 of "Practical Cryptography". It is > very simple and I believe I implemented it correctly (test case), so > the difference in the test results is probably due to your test using a > different padding scheme. > The tests that I'm running are only one sided tests, they say encrypt this and your answer should be this. Since the encryption test didn't assume any padding the results are different, but only by the padding itself. _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
RE: Re: block-based cipher padding
|
|
> The tests that I'm running are only one sided tests, they say encrypt
> this > and your answer should be this. Since the encryption test didn't > assume any > padding the results are different, but only by the padding itself. Ah, I thought the encryption test DID use some kind of padding. So if it isn't using padding you probably don't want to use our code that does padding, right? IOW, this sounds like a lower-level test of just the underlying AES w/ CBC (using three blocks) rather than a test of encryption of an arbitrary-sized ByteArray. Arbitrary-sized ByteArray's are encrypted/decrypted with the #encrypt:/#decrypt: methods, respectively. But you just want to encrypt three blocks so you need to use #encryptBlock: and #decryptBlock. They're the lower-level functionality that will match the test you're doing, they don't do any padding. _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
RE: Re: block-based cipher padding
|
|
> From: Chris Muller
> Sent: Tuesday, July 11, 2006 1:39 PM > > > The tests that I'm running are only one sided tests, they say encrypt > > this > > and your answer should be this. Since the encryption test didn't > > assume any > > padding the results are different, but only by the padding itself. > > Ah, I thought the encryption test DID use some kind of padding. So if > it isn't using padding you probably don't want to use our code that > does padding, right? > > IOW, this sounds like a lower-level test of just the underlying AES w/ > CBC (using three blocks) rather than a test of encryption of an > arbitrary-sized ByteArray. Arbitrary-sized ByteArray's are > encrypted/decrypted with the #encrypt:/#decrypt: methods, respectively. > But you just want to encrypt three blocks so you need to use > #encryptBlock: and #decryptBlock. They're the lower-level > functionality that will match the test you're doing, they don't do any > padding. The tests do not use padding but do have multiple blocks. It doesn't seem wise to break the blocks myself for testing, so I used encrypt: , I guess I could have used the encrypt:from:to: method but it seems redundant. Maybe we should have a encrypt:usePadding: method? I did like the idea of abstracting the padding methods to allow for their replacement by developers. The encrypt: method could use your padding by default but then we could have a noPadding option. BlockCipherPaddingAbstract BlockCipherPaddingNoPadding BlockCipherPaddingFergusonSchneier2 ... It would make it much easier to add new padding schemes later. What do you think? Ron Teitelbaum _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
«
Return to Squeak - Cryptography
|
1 view|%1 views
| Free forum by Nabble | Edit this page |