On Thu, Sep 06, 2007 at 05:03:42PM +0200, Rik Snel wrote:
> 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 implementa
Hi Rik,
I played with xts+dm-crypt on a 4GiB partition for a while and my box
did not hang.
I added some comments after init_tfm() where *I* think it is more
readable that way. Using ctx->tweak and ctx->child instead of child in
setkey() might be also better. However, this is my personal taste :)
Hello,
On Fri, Sep 07, 2007 at 08:38:32PM +0200, Sebastian Siewior wrote:
> [...]
>
> >Christoph encountered a deadlock after a few hours and 16GB of data (on
> >an aes-xts-plain partition). Assuming there is an error in xts.c, is
> >there an obvious way of finding it?
>
> Haven't seen any locks
* [EMAIL PROTECTED] | 2007-09-06 16:57:26 [+0200]:
>> The compiler should generate similar code.
>
>I'd rather tell the compiler what I want than to introduce a new local
>variable and a conditional branch in the hope that the compiler will
>optimize it away, just to avoid a goto.
>
>If you insist
On Thu, Sep 06, 2007 at 04:57:26PM +0200, [EMAIL PROTECTED] wrote:
>
> I'd rather tell the compiler what I want than to introduce a new local
> variable and a conditional branch in the hope that the compiler will
> optimize it away, just to avoid a goto.
Yes this code looks OK to me.
Cheers,
--
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
Hello Sebastian,
Thanks for your review of the patch. I will address your points below.
On Wed, Sep 05, 2007 at 02:29:06AM +0200, Sebastian Siewior wrote:
> >diff --git a/crypto/xts.c b/crypto/xts.c
> [...]
> >+/* key consists of keys of equal size concatenated, therefore
> >+ * the lengt
* Rik Snel | 2007-09-03 23:45:16 [+0200]:
>diff --git a/crypto/xts.c b/crypto/xts.c
>new file mode 100644
>index 000..7d9a353
>--- /dev/null
>+++ b/crypto/xts.c
>@@ -0,0 +1,277 @@
>+/* XTS: as defined in IEEE1619/D16
>+ *http://grouper.ieee.org/groups/1619/email/pdf00086.pdf
>+ *(secto
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
