[botan-devel] encryption question

Tim Prepscius timprepscius at gmail.com
Thu Jan 31 16:38:38 EST 2013


Ok, I have one follow up question.

The reason I am choosing a new AES key for each file is because of this:

1. User A sends user B a plain text message M.
2. User B uses AES/CBC/PK.. to encrypt plain text message in Encoded-M.
3. User A steals Encoded-M.

4. User A uses expensive hardware to break AES-Key of single file.
5. User A reads all of the rest of user B's files.

--

So I have a question about AES key per file generation.  (instead of
storing, I agree with you it would be far better if I could compute it
with a one way hash.)

Let's say I had a seed data segment which is random. Let's say it is
256 bytes long..
Let's say I have 10000 files who's names are 8 bytes long.

1.Are SHA-256 of ("filename" + "random data segment)  and
SHA-256("random data segment" + "filename") cryptographically
different?

I mean, I know the results are different.  My instinct tells me to
place the file name first.  But in real math-wise, does it make any
difference?


2. How breakable is this?  Let's say my adversary has, (arbitrary) 10
million dollars to spend on hardware.   How long will it take for him
to be able to read all of the files?

Meaning, break AES for single file, break SHA-256 data segment for AES
key generation.
Generate AES keys for all files, read them all.


Thank you very much!

I know this stuff sounds a bit implausible.  But .. please bear with me. :-)

-tim


On 1/30/13, Tim Prepscius <timprepscius at gmail.com> wrote:
> 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