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
