kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-26 18:16:26 +00:00
Code Issues Releases Packages Activity
linux/crypto/xts.c

291 lines
7.1 KiB
Raw Normal View History

[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00
[CRYPTO] xts: Use proper alignment The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-03-06 18:56:19 +08:00
[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00
[CRYPTO] xts: Use proper alignment The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-03-06 18:56:19 +08:00
[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00
[CRYPTO] xts: Use proper alignment The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-03-06 18:56:19 +08:00
[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00
[CRYPTO] xts: Use proper alignment The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-03-06 18:56:19 +08:00
[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00
[CRYPTO] xts: Use proper alignment The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-03-06 18:56:19 +08:00
[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00
[CRYPTO] xts: Use proper alignment The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-03-06 18:56:19 +08:00
[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by: Rik Snel <rsnel@cube.dyndns.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-09-19 20:23:13 +08:00