[botan-devel] encryption question

Tim Prepscius timprepscius at gmail.com
Fri Feb 1 08:24:30 EST 2013


Wow.

This blows my mind.



-tim

On 2/1/13, Falko Strenzke <strenzke at flexsecure.de> wrote:
>
>
> On 01.02.2013 13:36, Tim Prepscius wrote:
>> On the topic of the key generation, I understand, and this I my method.
>>
>> However,
>> I am still confused about the first part though.  I probably explained
>> it poorly.
>> Let me try once more.
>>
>>
>> User A sends user B a plain text message.  Maybe 10K of the letter 'A'.
>>
>> User B, unfortunately, MUST encrypt every message he receives.
>> And, because of the nature of User A.   He can steal encrypted
>> messages from user B without user B knowing.
>>
>>
>>
>> This is what I was thinking in my head:
>>
>> If User A knows the plain text and the cipher text, and has an unlimited
>> budget.
>> Are you basically saying that User A still cannot break the  AES-256 Key?
> Yes, this is what I'm saying. Otherwise AES would have to be considered
> broken.
>
> Regards,
> Falko
>>
>>
>>
>> -tim
>>
>>
>> On 2/1/13, Falko Strenzke <strenzke at flexsecure.de> wrote:
>>> Hello Tim,
>>>
>>> On your argument concerning key usage and your question concerning AES
>>> security:
>>>
>>> this is not a realistic threat: AES, even AES-128, is considered to be
>>> secure. If you want to be on the safe side, use AES-256.
>>>
>>> Also note, given you used a cipher that could be broken in the way you
>>> describe, that your arguments are still not useful in general: If an
>>> attacker can break one message with this method, he can do this to any
>>> message. Such arguments are only useful when you can make a very exact
>>> calculation of attack cost and resulting gain for the attacker
>>> respectively damage for you. This is impossible or difficult most of
>>> time. Cryptography is designed to offer unconditional security based on
>>> current technology.
>>>
>>> Also your previously proposed approach wouldn't even prevent the attack,
>>> at least not in one "direction" of the message sequence.
>>>
>>> On your question concering key generation:
>>>
>>> Concerning your application, the order filename and nonce is irrelevant.
>>> This plays only a role for collision and length extension attacks, both
>>> of which do not apply for this type of key derivation. And when they
>>> matter, they should be mitigated by using a Message Authentication Code
>>> such as HMAC.
>>>
>>> What you should do is the following: create a fixed nonce of the the
>>> same length as your AES key, e.g. 256 bit for AES-256. Then prepend or
>>> append the varying nonce and hash the resulting string. If you use
>>> SHA-256, the output will already be of the length you need for the AES
>>> key and you can directly use it for the encryption of the file.
>>>
>>> Regards,
>>> Falko
>>>
>>> On 31.01.2013 22:38, Tim Prepscius wrote:
>>>> 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