[botan-devel] encryption question

Tim Prepscius timprepscius at gmail.com
Wed Jan 30 14:10:10 EST 2013


Actually, this is exactly the information I needed.

Very very helpful.

Thanks,

-tim

On 1/30/13, Falko Strenzke <strenzke at flexsecure.de> wrote:
> Hello Tim,
>
> I do not really understand what you mean. You say you use non null IVs
> throughout with one exception.
> First of all, not being a string of zeroes doesn't yet qualify an IV: it
> has to be chosen randomly and equally distributed from the space of the
> strings of the respective size.
> Second, I cannot understand your exception. What has the start of the
> plaintext to do with the IV choice?
>
> I can, however, explain what you have to do in order to use your
> symmetric encryption scheme correctly:
> For the creation of every ciphertext, first create a random IV. Then CBC
> encrypt the padded message. If you do this, nothing can go wrong.
>
> But note the following: As far as I understand, you are implementing
> some sort of storage encryption. In this case, to have all security
> guarantees from the symmetric encryption scheme (AES/CBC), for every
> modification of the plaintext you would have to entirely re-encrypt it,
> including the creation of a new random IV. But usually, for instance in
> hard disk encryption, the resulting leakage of equal message beginings
> from the use of constant IVs is accepted.
>
> I hope that answered your question, otherwise feel free to provide some
> more details about your problem and I will see if I can help
>
> Regards,
> Falko
>
> On 29.01.2013 20:05, Tim Prepscius wrote:
>> 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.
>>>
>>>
>
>
> --
>
> ----------------------------
> 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