On Sun, 2019-03-24 at 19:57 +0100, Niels Möller wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
>
> > Simo Sorce writes:
> >
> > > I am attaching all 3 patches anew as I also fixed the other issues you
> > > mentioned in a previous email.
> >
> > Thanks. I'm about to merge. I've run cross-
ni...@lysator.liu.se (Niels Möller) writes:
> Simo Sorce writes:
>
>> I am attaching all 3 patches anew as I also fixed the other issues you
>> mentioned in a previous email.
>
> Thanks. I'm about to merge. I've run cross-compile+qemu tests also on
> big-endian mips, and it seems to work fine.
M
Simo Sorce writes:
> I am attaching all 3 patches anew as I also fixed the other issues you
> mentioned in a previous email.
Thanks. I'm about to merge. I've run cross-compile+qemu tests also on
big-endian mips, and it seems to work fine.
> +@subsubsection @acronym{XTS}-@acronym{AES} interface
On Wed, 2019-03-20 at 14:46 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > On Wed, 2019-03-20 at 06:14 +0100, Niels Möller wrote:
> > > And another possible trick for big-endian is to do an "opposite-endian"
> > > left shift as
> > >
> > > ((x & 0x7f7f7f7f7f7f7f7f) << 1) | ((x & 0x80808
Simo Sorce writes:
> On Wed, 2019-03-20 at 06:14 +0100, Niels Möller wrote:
>> And another possible trick for big-endian is to do an "opposite-endian"
>> left shift as
>>
>> ((x & 0x7f7f7f7f7f7f7f7f) << 1) | ((x & 0x8080808080808080) >> 15)
>> where this bit is the ca
Simo Sorce writes:
> If it is ok to make configure if those macros are available
> (/usr/include/endian.h) I would use them or provide replacements that
> just call into the existing macros.
Sure, provided there's a reasonable portable fallback. On non-glibc
systems, I think we should use __bui
On Wed, 2019-03-20 at 06:52 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > Ok, I took a stab at removing xts_steal completely in the second patch,
> > let me know what you think, I think I may like it better than my
> > original code and uses nettle_block16 for temporary storage to avoid a
On Wed, 2019-03-20 at 06:14 +0100, Niels Möller wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
>
> > 3. Big-endian system, no __builtin_bswap64. Here we can either use the
> >current code, with byte accesses only. Or attempt to define byteswap
> >without builtins and follow 2. I'd le
On Tue, 2019-03-19 at 22:36 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > Just for curiosity, would it be ok change,
> > LE_READ_UINT64/LE_WRITE_UINT64 to use uint64_t and have the macro use
> > __bswap64 if available or fall back to the original unoptimized code ?
>
> I think LE_READ_UI
Simo Sorce writes:
> Ok, I took a stab at removing xts_steal completely in the second patch,
> let me know what you think, I think I may like it better than my
> original code and uses nettle_block16 for temporary storage to avoid a
> copy.
I like the version without xts_steal.
It's slightly an
ni...@lysator.liu.se (Niels Möller) writes:
> 3. Big-endian system, no __builtin_bswap64. Here we can either use the
>current code, with byte accesses only. Or attempt to define byteswap
>without builtins and follow 2. I'd lean towards using the current
>code, unless there's some syste
Simo Sorce writes:
> Just for curiosity, would it be ok change,
> LE_READ_UINT64/LE_WRITE_UINT64 to use uint64_t and have the macro use
> __bswap64 if available or fall back to the original unoptimized code ?
I think LE_READ_UINT64 and related macros should be left as is,
and used for unaligned
Hi Niels,
attached find two patches, comments inline.
On Tue, 2019-03-19 at 07:31 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > New patch attached, the diff has also been applied as an additional commit
> > to my xts_exploded tree in gitlab.
>
> Thanks. Looks pretty good, a few more co
Simo Sorce writes:
> New patch attached, the diff has also been applied as an additional commit to
> my xts_exploded tree in gitlab.
Thanks. Looks pretty good, a few more comments below.
Id din't look so closely at the tests, but it would be good with to test
inplace opertion also with the aes
On Sat, 2019-03-16 at 16:26 +0300, Yuriy M. Kaminskiy wrote:
> On 03/15/19 16:33 , Simo Sorce wrote:
> > On Fri, 2019-03-15 at 09:27 -0400, Simo Sorce wrote:
> > > > I think this is the same as block_mulx, in cmac.c. (Also same byte
> > > > order, right?)
> > >
> > > Looks the same indeed, should
On 03/15/19 16:33 , Simo Sorce wrote:
> On Fri, 2019-03-15 at 09:27 -0400, Simo Sorce wrote:
>> > I think this is the same as block_mulx, in cmac.c. (Also same byte
>> > order, right?)
>>
>> Looks the same indeed, should I share it? Just copy it from cmac?
>> Something else?
>
> Turns out the algo
On Fri, 2019-03-15 at 17:46 -0400, Simo Sorce wrote:
> On Fri, 2019-03-15 at 22:33 +0100, Niels Möller wrote:
> > Simo Sorce writes:
> >
> > > Turns out the algorithm is not equivalent, as the shift is applied to
> > > the array as if it were a big 128bit little endian value, the endianess
> > >
On Fri, 2019-03-15 at 22:33 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > Turns out the algorithm is not equivalent, as the shift is applied to
> > the array as if it were a big 128bit little endian value, the endianess
> > of the two is different.
>
> Ah, I see.
>
> > /* shift one and
Simo Sorce writes:
> Turns out the algorithm is not equivalent, as the shift is applied to
> the array as if it were a big 128bit little endian value, the endianess
> of the two is different.
Ah, I see.
> /* shift one and XOR with 0x87. */
> /* src and dest can point to the same buffer for in-
On Fri, 2019-03-15 at 16:33 -0400, Simo Sorce wrote:
> On Fri, 2019-03-15 at 09:27 -0400, Simo Sorce wrote:
> > > I think this is the same as block_mulx, in cmac.c. (Also same byte
> > > order, right?)
> >
> > Looks the same indeed, should I share it? Just copy it from cmac?
> > Something else?
>
On Fri, 2019-03-15 at 09:27 -0400, Simo Sorce wrote:
> > I think this is the same as block_mulx, in cmac.c. (Also same byte
> > order, right?)
>
> Looks the same indeed, should I share it? Just copy it from cmac?
> Something else?
Turns out the algorithm is not equivalent, as the shift is applied
On Fri, 2019-03-15 at 17:30 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > > But it looks like one has to pass the complete message to one call?
> >
> > Yes, due to ciphertext stealing, XTS needs to know what are the last
> > two blocks, or at the very least needs to withhold the last pro
Simo Sorce writes:
>> But it looks like one has to pass the complete message to one call?
>
> Yes, due to ciphertext stealing, XTS needs to know what are the last
> two blocks, or at the very least needs to withhold the last processed
> block in order to be able to change it if a final partial bl
On Fri, 2019-03-15 at 13:14 +0100, Niels Möller wrote:
> Simo Sorce writes:
>
> > The attached patch implements the XTS block cipher mode, as specified
> > in IEEE P1619. The interface is split into a generic pair of functions
> > for encryption and decryption and additional AES-128/AES-256 varia
Simo Sorce writes:
> The attached patch implements the XTS block cipher mode, as specified
> in IEEE P1619. The interface is split into a generic pair of functions
> for encryption and decryption and additional AES-128/AES-256 variants.
Thanks. Sorry for the late response.
> The function signat
Hello,
The attached patch implements the XTS block cipher mode, as specified
in IEEE P1619. The interface is split into a generic pair of functions
for encryption and decryption and additional AES-128/AES-256 variants.
The function signatures follows the same pattern used by other block-
cipher m
26 matches
Mail list logo
