[botan-devel] encryption question

Tim Prepscius timprepscius at gmail.com
Tue Jan 29 14:05:15 EST 2013


Thank you for this response.  I'm mulling it over.

I have one more question, and I think the answer is, "this will have
an incredibly small effect on the strength of encryption, but you
should fix it anyway."


But, I just wanted to check.  Because, if it's not an issue, or so
small of an issue it doesn't have any practical impact, I'd rather
just keep things as they are.


---

For the AES encryption I am using: AES/CBC/PKCS5Padding
With a non null IV.  Non null IV except for one instance.  And that
one instance bugs me.


So, here's the thing.  Every data segment is, before encryption,
zipped.  But zipped so that it retains it's header and crc.

That means the encryption is really AES of
(0x78-0x9c,data-segment-zipped,4bytes-crc,pkcs5-padding);


Does the existence of the "0x78,0x9c zip header" in anyway decrease
the strength of the AES?
I have been pondering whether or not I should pre-pad with non zero
random bytes.  Although, this is essentially what the non null IV is
for, correct?

If the IV was null, AND there was (0x78,0x9c), would this be problematic?


--tim



On 1/29/13, Falko Strenzke <strenzke at flexsecure.de> wrote:
> Hello Tim,
>
> from a security perspective I don't see any problem with your approach,
> except for chosen ciphertext security: for RSA, you don't mention the
> encryption method, so it remains open whether you use one that provides
> chosen ciphertext security. For the symmetric encryption, you obviously
> don't plan to include any means of authentication, leaving you without
> security against such attacks. Since I don't know how your application
> works, I cannot determine whether this actually leads to security problems.
>
> Concerning the performance, however, why don't simply encrypt everything
> with the same key?
> If for some reason (that I cannot really think of) you need to use
> different AES keys for each file, then you could RSA-encrypt a seed
> resp. nonce value and generate AES keys for each file by appending a
> different file specific index after the seed resp. nonce and encrypt or
> hash (i.e. use it as input for pseudorandom function) the resulting
> string. The output would be the AES key for the respective file.
>
> Regards,
> Falko
>
> On 28.01.2013 18:00, botan-devel-request at randombit.net wrote:
>> Send botan-devel mailing list submissions to
>> 	botan-devel at randombit.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.randombit.net/mailman/listinfo/botan-devel
>> or, via email, send a message with subject or body 'help' to
>> 	botan-devel-request at randombit.net
>>
>> You can reach the person managing the list at
>> 	botan-devel-owner at randombit.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of botan-devel digest..."
>>
>>
>> Today's Topics:
>>
>>    1. encryption question (Tim Prepscius)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 28 Jan 2013 10:20:42 -0500
>> From: Tim Prepscius <timprepscius at gmail.com>
>> To: Botan development list <botan-devel at randombit.net>
>> Subject: [botan-devel] encryption question
>> Message-ID:
>> 	<CAAJ3AvVMzT-xbb-c72Vf6qa6gKzYrWo7tdt5uWbK9uf7AnGzuQ at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Greetings,
>>
>> This is more of a general encryption question rather than a botan
>> question.   However, I respect you guys, and need a second opinion.
>>
>> So, long story short: I have an application which currently has a set of
>> files.
>> Each file is:  RSA Encrypted(AES-key)  + AES-key encrypted(value).
>>
>> Standard stuff.  No worries.
>>
>>
>> Because of performance reasons, I need to move away from RSA except
>> when absolutely necessary.
>>
>> So I'm thinking of doing this:
>>
>> File1: RSA Encrypted(AES-key#1) + AES-key#1 encrypted(value + AES-key#2)
>> File2: AES-key#2 encrypted(value + AES-key#3)
>> File3: AES-key#3 encrypted(value + AES-key#4)
>> File4: AES-key#4 encrypted(value + AES-key#5)
>>
>> Etc, etc.   The information I'm leaving out is that the files actually
>> form a tree, not a simple chain.  And that the root of the tree is the
>> File1.  Also, there will be thousands of leaves.
>>
>>
>>
>>
>> My question is this:
>>
>> By using this series of AES-keys encrypted by previous AES-keys, am I
>> somehow weakening the encryption.  Somehow I've though to myself, "I'm
>> leaking information," even though I have no basis for this suspicion.
>>
>>
>>
>> Any thoughts are greatly appreciated.
>>
>> -tim
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> botan-devel mailing list
>> botan-devel at randombit.net
>> http://lists.randombit.net/mailman/listinfo/botan-devel
>>
>>
>> ------------------------------
>>
>> End of botan-devel Digest, Vol 95, Issue 13
>> *******************************************
>
>
>
> --
>
> ----------------------------
> Dipl.-Phys.
> Falko Strenzke
>
> FlexSecure-Logo    KobilGroup-Logo
>
> FlexSecure GmbH
> Industriestr. 12
> D - 64297 Darmstadt
> Tel: +49 (0) 6151 501 23-14
> Fax: +49 (0) 6151 501 23-19
> E-Mail: strenzke at flexsecure.de
> Internet: www.flexsecure.de
>
> Geschäftsführer:
> Erwin Stallenberger, Markus Ruppert
>
> Amtsgericht Darmstadt HRB 8036
> Umsatzsteuernummer: DE 214745269
>
> Die Information in dieser E-Mail ist vertraulich und exklusiv für den
> Adressatenkreis bestimmt. Unbefugte Empfänger haben kein Recht, vom Inhalt
> Kenntnis zu nehmen, fehlgeleitete E-Mails sind sofort zu löschen.
> Die FlexSecure GmbH ist von der Richtigkeit des Inhalts und der Übertragung
> dieser E-Mail überzeugt. Eine Haftung dafür ist jedoch ausgeschlossen.
> *************************************************************************************************
> Registry Court: Local Court Darmstadt, Registry No: HRB 8036
> Chief Executive Officer: Erwin Stallenberger, Markus Ruppert, Registered
> Office:
> Darmstadt, Germany
>
> This is a confidential communication intended only for the named addressee.
> If
> you have received this communication in error, please notify us and return
> and
> delete it without reading it. Whilst FlexSecure GmbH believes that the
> information is correct at the date of the e-mail, no warranty and
> representation
> is given to this effect and no responsibility can be accepted by FlexSecure
> GmbH.
>
>



More information about the botan-devel mailing list