Re: Freescale SEC1 and AEAD / IPSEC
On Thu, Apr 24, 2014 at 9:34 AM, leroy christophe christophe.le...@c-s.fr wrote: I'm progressing well on the SEC1 implementation. I now have HASH (non HMAC) , DES and AES working properly. Why DES? More than a decade ago, the first Linux IPsec implementation refused to do single DES because it was known to be insecure. http://www.freeswan.org/freeswan_trees/freeswan-1.97/doc/faq.html#noDES.faq At that time, we had to have DES internally so we could implement triple DES. We just did not provide single DES in the user interface or the list of cipher suites we would negotiate. Today you could consider dropping DES entirely since AES is so widespread, far faster than triple DES, and thought secure. As of 2001 or so, it roughly doubled IPsec throughput: http://www.freeswan.org/freeswan_trees/freeswan-1.97/doc/performance.html#perf.more Today it probably does even better; there has been a lot of work on optimising it. So it is now time to look at AEAD. A fine idea. AES-GCM is the first obvious candidate. Newer work includes: http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00 There is a competition for new AEAD methods, still in early stages so it does not yet give any solid results you could implement. Likely worth a look, though: http://competitions.cr.yp.to/caesar.html https://aezoo.compute.dtu.dk/doku.php I don't know much yet about crypto algorithm so forgive me if I ask stupid questions. An area that was a problem a decade ago was forward secrecy. http://www.freeswan.org/freeswan_trees/freeswan-1.97/doc/interop.html#req.features FreeS/WAN default is to provide perfect forward secrecy. ... The PFS settings on the two ends must match. There is no provision in the protocol for negotiating whether to use PFS; you need to either set both ends to use it or set them both not to. The difference is what happens if an enemy gets the keys used in authenticating connection setup. Without PFS, that lets him obtain actual encryption keys and read everything sent on those connections, possibly including old messages he has archived. With PFS he gets no message content without doing a man-in-the-middle attack (using the authentication keys to trick servers into giving him data that lets him get encryption keys), he has to do another such attack every time you change keys, and there is no way to do one for old messages. I do not know if the revised RFCs have fixed this, but I am very much of the opinion that PFS should be the default everywhere. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: crypto: skein: depend upon CRYPTO
Fengguang's randconfig kernel build tester discovered the following warnings: warning: (CRYPTO_THREEFISH) selects CRYPTO_ALGAPI which has unmet direct dependencies (CRYPTO) warning: (DM_VERITY CRYPTO_SKEIN) selects CRYPTO_HASH which has unmet direct dependencies (CRYPTO) Fix this in the Kconfig by depending on CRYPTO. Reported-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Jason Cooper ja...@lakedaemon.net --- drivers/staging/skein/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig index 8f5a72a90ced..b9172bfcdc1b 100644 --- a/drivers/staging/skein/Kconfig +++ b/drivers/staging/skein/Kconfig @@ -1,6 +1,6 @@ config CRYPTO_SKEIN bool Skein digest algorithm - depends on (X86 || UML_X86) 64BIT + depends on (X86 || UML_X86) 64BIT CRYPTO select CRYPTO_THREEFISH select CRYPTO_HASH help @@ -17,7 +17,7 @@ config CRYPTO_SKEIN config CRYPTO_THREEFISH bool Threefish tweakable block cipher - depends on (X86 || UML_X86) 64BIT + depends on (X86 || UML_X86) 64BIT CRYPTO select CRYPTO_ALGAPI help Threefish cipher algorithm is the tweakable block cipher underneath -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] crypto: caam: Error reporting fixes
On Apr 24, Marek wrote: First stab at reworking the error.c thing in Freescale CAAM. This patchset cleans it up so it's not doing any too insane string messing anymore. NOTE: Can someone please test this on real hardware? I have none at hand, so THIS IS COMPILE-TESTED ONLY! Marek Vasut (11): crypto: caam: Contain caam_jr_strstatus() ugliness crypto: caam: Pull all the error codes out crypto: caam: Implement fast-path for error codes with no handler crypto: caam: Pass error type into the functions crypto: caam: Kill the easy targets crypto: caam: Dissolve report_jump_idx() crypto: caam: Clean up report_ccb_status() crypto: caam: Clean up report_deco_status() crypto: caam: Kill SPRINTFCAT() with fire crypto: caam: Sweep the remnants crypto: caam: Fix the 'quoted string split across lines' drivers/crypto/caam/caamalg.c | 28 +-- drivers/crypto/caam/caamhash.c | 28 +-- drivers/crypto/caam/caamrng.c | 7 +- drivers/crypto/caam/error.c| 389 +++-- drivers/crypto/caam/error.h| 2 +- drivers/crypto/caam/key_gen.c | 7 +- 6 files changed, 200 insertions(+), 261 deletions(-) Signed-off-by: Marek Vasut ma...@denx.de Cc: Herbert Xu herb...@gondor.apana.org.au Cc: Horia Geanta horia.gea...@freescale.com Thanks for doing this! The final result looks good to me, though I too can't test with real hardware. Please consider the whole series: Reviewed-by: Kees Cook keesc...@chromium.org Thanks, -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
