From mboxrd@z Thu Jan  1 00:00:00 1970
From: bin4ry <0xbin4ry@gmail.com>
Date: Mon, 30 Sep 2013 09:51:54 +0200
Subject: [U-Boot] AES: Encryption of u-boot.img
In-Reply-To: <20130915080835.44798b38@lilith>
References: <1379054763-7406-1-git-send-email-Shengzhou.Liu@freescale.com>
	<1379054763-7406-4-git-send-email-Shengzhou.Liu@freescale.com>
	<523327D0.6050708@gmail.com> <20130915080835.44798b38@lilith>
Message-ID: <52492D9A.3050503@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Albert,

so if I get you right the workflow for payload authentication is the
following:

Encryption process:

1. Create hash value H for u-boot.img
2. Encrypt the hash value H with secret K to get encrypted hash values H_enc
3. Store H_enc

Decryption process:

1. Read H_enc
2. Decrypt H_enc using secret K to get plain hash values H
3. Create Hash values H' of u-boot.img
4. Compare H and H'

Did I get you right?

Thanks and best regards,
-b

Am 15.09.2013 08:08, schrieb Albert ARIBAUD:
> What's the point of encrypting the whole binary? Secure boot usually
> uses authentication, not encryption, of the payload that is to be
> secured: instead of decrypting several hundreds of KBs, you hash them
> (which is faster) and decrypt only the few hundreds bits of the
> encrypted hash in order to compare both hashes (but trust chain remains
> the same of course).
>
> Note: if you chose payload encryption over authentication (hash
> encryption) because you are worried about collision, preimage or even
> second preimage resistance, then you should just go with use a stronger
> hash function. Besides, for a small and compact payload such as a
> bootloader, the risks of collisions are reduced because there is less
> room in the input space.
>
> Amicalement,