[botan-devel] encryption question

Falko Strenzke strenzke at flexsecure.de
Wed Jan 30 02:12:15 EST 2013


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20130130/15ad0a99/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flexsecure_logo_cmyk.png
Type: image/png
Size: 16621 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20130130/15ad0a99/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kobil_group.jpg
Type: image/jpeg
Size: 2502 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20130130/15ad0a99/attachment.jpg>


More information about the botan-devel mailing list