[botan-devel] encryption question

Falko Strenzke strenzke at flexsecure.de
Fri Feb 1 08:14:15 EST 2013



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.
>>>>>
>>>>>
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2953 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20130201/cacaef33/attachment.p7s>


More information about the botan-devel mailing list