Home
last modified time | relevance | path

Searched hist:f19f5111c94053ba4931892f5c01c806de33942e (Results 1 – 6 of 6) sorted by relevance

/openbmc/linux/include/crypto/
H A Dgf128mul.hf19f5111c94053ba4931892f5c01c806de33942e Wed Sep 19 07:23:13 CDT 2007 Rik Snel <rsnel@cube.dyndns.org> [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>
/openbmc/linux/crypto/
H A Dtcrypt.hf19f5111c94053ba4931892f5c01c806de33942e Wed Sep 19 07:23:13 CDT 2007 Rik Snel <rsnel@cube.dyndns.org> [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>
H A Dxts.cf19f5111c94053ba4931892f5c01c806de33942e Wed Sep 19 07:23:13 CDT 2007 Rik Snel <rsnel@cube.dyndns.org> [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>
H A DMakefilef19f5111c94053ba4931892f5c01c806de33942e Wed Sep 19 07:23:13 CDT 2007 Rik Snel <rsnel@cube.dyndns.org> [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>
H A Dtcrypt.cf19f5111c94053ba4931892f5c01c806de33942e Wed Sep 19 07:23:13 CDT 2007 Rik Snel <rsnel@cube.dyndns.org> [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>
H A DKconfigf19f5111c94053ba4931892f5c01c806de33942e Wed Sep 19 07:23:13 CDT 2007 Rik Snel <rsnel@cube.dyndns.org> [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>