mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: "Jan Lübbe" <jlu@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 3/4] FIT: add FIT image support
Date: Fri, 13 Mar 2015 15:28:08 +0100	[thread overview]
Message-ID: <20150313142808.GC23879@ns203013.ovh.net> (raw)
In-Reply-To: <1426242065.13791.110.camel@pengutronix.de>

On 11:21 Fri 13 Mar     , Jan Lübbe wrote:
> On Fr, 2015-03-13 at 11:05 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 10:28 Fri 13 Mar     , Jan Lübbe wrote:
> > > On Do, 2015-03-12 at 19:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > please do not send a new version except for fix
> > > > 
> > > > I'm going to re-integrate it with the keystore & co
> > > 
> > > Could you describe your keystore design?
> > 
> > I'll send the patch series soon
> > 
> > code is better than 1000s of words
> > 
> > with DER support and the fit
> 
> Thanks.
> 
> > > > and sha1,rsa2048 is considered weak in term of security
> > > > and worse md4/md5
> > > > 
> > > > for barebox I would only use
> > > > at least sha256 with rs2048 or sha512 with rsa4096
> > > 
> > > Yes, of course. These were only used as an example and it's trivial to
> > > switch to other hash algos or RSA key sizes. Also, the FIT format can
> > > easily be extended to support ECC/Curve25519.
> > 
> > very slow vs rsa, but as we will use a generic framework we will just need to
> > add the algo
> > 
> > if you can break rsa4096, the chance you can break ECC are high too
> 
> Please see http://ed25519.cr.yp.to/ and
> http://cr.yp.to/papers.html#rwsota. Curve22519 is very fast and has some
> benefits over RSA.

I known this curve but I did not yet test it on barebox

remember on arm it's not as performent as on x86

and the ECC have advantage over RSA but the speed on my last test on ARM use
more power than RSA and was slower
> 
> I'm not arguing that either RSA or ECC are better for verified boot, we
> should just keep in mind that supporting ECC later should fit the
> design.

agreed that why I work on a framework to hide the algo at every level
key/signature verification, everywhere.

SO we do not care if it's a software implementation or a hardware one
and which algo
> 
> > > In some cases, where the SoC's ROM code only supports RSA2048 with SHA1,
> > > using stronger settings in Barebox doesn't increase security. So there
> > > we want to use the same settings as the ROM code.
> > 
> > agreed but I refuse to allow it unless we have no choice
> > and emit a warning
> 
> I'm fine with a warning in Kconfig or during compile time. 
> 
> > and even I'll prefer to use stonger, yes this will increase the security.
> > As a secure boot is as strong as it's weak link
> 
> It's not the job of barebox to define security policies, it must fit
> well into the larger security design, which may require compromises.

I disagree, disable by default non secure feature is require to pass
secure boot certification

Best Regards,
J.
> 
> Regards,
> Jan
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2015-03-13 14:28 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 14:39 [RFC 0/4] FIT Support Jan Luebbe
2015-03-12 14:39 ` [RFC 1/4] digest: Make filename arguments const Jan Luebbe
2015-03-13  7:40   ` Sascha Hauer
2015-03-12 14:39 ` [RFC 2/4] Add rsa support Jan Luebbe
2015-03-12 17:47   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13  9:35     ` Jan Lübbe
2015-03-13  9:56       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:06         ` Sascha Hauer
2015-03-13 10:12           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:22             ` Jan Lübbe
2015-03-13 10:26               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:10         ` Jan Lübbe
2015-03-13 10:25           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:43             ` Jan Lübbe
2015-03-13 15:49               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:00                 ` Jan Lübbe
2015-03-16 10:27                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 11:25                     ` Jan Lübbe
2015-03-16 11:33                       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 15:42                         ` Jan Lübbe
2015-03-17 10:48                           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-17 12:09                             ` Jan Lübbe
2015-03-17 12:39                               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-17 12:57                                 ` Jan Lübbe
2015-03-12 14:39 ` [RFC 3/4] FIT: add FIT image support Jan Luebbe
2015-03-12 18:19   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13  9:28     ` Jan Lübbe
2015-03-13 10:05       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:21         ` Jan Lübbe
2015-03-13 14:28           ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2015-03-13 15:41             ` Jan Lübbe
2015-03-13 16:08               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:19                 ` Jan Lübbe
2015-03-16 11:14                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 12:08                     ` Jan Lübbe
2015-03-16 12:19                       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 13:28                         ` Jan Lübbe
2015-03-16 13:51                           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 14:31                             ` Jan Lübbe
2015-03-16 14:40                               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 14:50                                 ` Jan Lübbe
2015-03-13 11:33         ` Marc Kleine-Budde
2015-03-13 15:54           ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 16:06             ` Marc Kleine-Budde
2015-03-13 17:00               ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:04                 ` Jan Lübbe
2015-03-16 10:28                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-12-29 10:18   ` Yegor Yefremov
2015-03-12 14:39 ` [RFC 4/4] FIT: add test config and data [do not merge] Jan Luebbe
2015-03-12 14:51 ` [RFC] digest: Add enum Jan Luebbe
2015-03-12 17:50   ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13  9:54     ` Jan Lübbe
2015-03-13 10:10       ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 18:50         ` Robert Schwebel
2015-11-11 11:39 ` [RFC 0/4] FIT Support Yegor Yefremov
2015-11-13 11:35   ` Antony Pavlov
2015-11-13 12:54   ` Sascha Hauer
2015-12-29  8:10     ` Yegor Yefremov
2016-01-05  8:11     ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150313142808.GC23879@ns203013.ovh.net \
    --to=plagnioj@jcrosoft.com \
    --cc=barebox@lists.infradead.org \
    --cc=jlu@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox