Re: Nettle ECC code question
Dmitry Eremin-Solenikov writes: > Ok, thanks for the clarification. Is it only the case for 521-bit curve > and for redc-based reduce? Because for all other cases 2 * p > B, so > mul (and sqr) can not return value greater or equal to 2*m (= 2 * p). Not sure I understand the question. For a reduced value t (output of ecc->mod or ecc->reduce), we always have both r < B (fits in ecc->size limbs) and r < 2 m. Now, it's true that for many of the ecc-related moduli, we have 2 m > B, so that r < B ==> r < 2 m, but that makes little difference in this context. In either case, to reduce r to the canonical range 0 <= r < m, one conditional subtraction is needed. One complication is that ecc_mod_add and ecc_mod_sub do *not* ensure r < 2 m, only r < B. So for moduli where 2 m < B, it's possible to get outputs t >= 2m. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle ECC code question
Dmitry Eremin-Solenikov writes: > After ecc_modp_mul() call value of `t` should be already lower than > `ecc->p.m`. So subtract will always return a carry. No, the reduction after mul and sqr doesn't produce canonical results. They only ensure that than t < 2*m. The pattern you see is needed in places where a canonical representation, t < m, is required. Result is the same as with if (mpn_cmp(...)) mpn_sub_n(...), but an unconditional subtraction + cnd_cpy makes that logic side-channel silent. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: PowerMac G5 results
Jeffrey Walton writes: > Hi Everyone, > > I'm building Nettle 3.5.1 on an old PowerMac G5. > > gcc -I. -I/usr/local/include -DNDEBUG -DHAVE_CONFIG_H -g2 -O2 -fPIC > -pthread -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes > -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith > -Wbad-function-cast -Wnested-externs -fPIC -MT xts-aes128.o -MD -MP > -MF xts-aes128.o.d -c xts-aes128.c \ > && true > xts.c: In function 'xts_shift': > xts.c:59: warning: integer constant is too large for 'long' type > xts.c:59: warning: integer constant is too large for 'long' type > xts.c:60: warning: integer constant is too large for 'long' type > xts.c:60: warning: integer constant is too large for 'long' type > xts.c:60: warning: integer constant is too large for 'long' type This looks like it may be a real problem on big-endian 32-bit machines. A bit surprised that tests don't fail, the ci runs tests on (emulated) mips, and I also did pre-release tests on m68k. In the code on master, this code is moved to block-internal.h, and use UINT64_C for the constants. > One self test failure, unrelated to XTS mode: > > PASS: symbols > dlopen failed: dlopen(../libnettle.so, 2): image not found > ../run-tests: line 57: 86075 Abort trap "$1" $testflags > FAIL: dlopen Old problem, fixed recently, see https://git.lysator.liu.se/nettle/nettle/commit/c00f4b17f7f38c180ece4c92c50c05feb2e28c2d Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: charset parameter for https://www.lysator.liu.se/~nisse/nettle/nettle.html causing mojibake
Daniel Kahn Gillmor writes: > i notice that https://www.lysator.liu.se/~nisse/nettle/nettle.html is > served with the HTTP header: > > Content-Type: text/html; charset=iso-8859-1 > > but it contains non-ASCII text -- your name "Niels Möller", but it is > rendered as Niels Möller due to the charset parameter. It looks equally bad for me (in firefox). > You can update your nginx config by using the charset directive: > > charset UTF-8; I can ask the people maintaining this webserver. I think the nginx only acts as a reverse-proxy for an apache or possibly roxen server behind it. Other html files under https://www.lysator.liu.se/~nisse carries both a and a inside ..., which is supposed to override whatever the actual http headers say. And that seems to work. But nettle.html is generated with makeinfo and looks slightly different. The nettle.texinfo file includes @documentencoding UTF-8 and the generated nettle.html carries a but it seems that isn't enough. Any clues appreciated. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Dead links to bindings
Justus Winter writes: >> If you want to make it really easy for me, please send a patch, the file >> on the web should be a straight copy of >> https://git.lysator.liu.se/nettle/nettle/blob/master/index.html > > I didn't know that, thanks. Patches applied, thanks! > Btw, I just noticed that the links to the Pike, PostgreSQL, and R6RS > Scheme bindings are dead. Pike is alive, I've updated the link. The Postgres and scheme bindings, I don't know, anyone else? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] cfb8: don't truncate output IV if input is shorter than block size
Daiki Ueno writes: >> For testing, I think it would be good to take the testvectors for cfb8, >> and split into multiple calls to cfb8_*crypt, in several ways. And check >> they all give the same result. A bit like it's done in arcfour-test.c, >> or the test_cipher_stream (#if:ed out, not sure if it's worth reviving). > > Indeed, thank you for the suggestion. I'm attaching updated patches. Pushed now, with a few additional fixes for the test. Thanks! /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] cfb8: don't truncate output IV if input is shorter than block size
Daiki Ueno writes: > We realized that cfb8_decrypt doesn't update the IV correctly when the > input is shorter than AES block size. The attached patches should fix > it. For testing, I think it would be good to take the testvectors for cfb8, and split into multiple calls to cfb8_*crypt, in several ways. And check they all give the same result. A bit like it's done in arcfour-test.c, or the test_cipher_stream (#if:ed out, not sure if it's worth reviving). What do you think? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Rust bindings
Justus Winter writes: > Do we need to do anything else to be listed on > https://www.lysator.liu.se/~nisse/nettle/ ? If you want to make it really easy for me, please send a patch, the file on the web should be a straight copy of https://git.lysator.liu.se/nettle/nettle/blob/master/index.html Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] Curve point decompression
ni...@lysator.liu.se (Niels Möller) writes: > Not sure in which order to do things. Maybe it will be best to first add > the square root routines, with tests, and then add functions for > converting between points and octet strings (and related utilities, if > needed). I've now pushed some preparatory changes to the branch ecc-sqrt. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: ANNOUNCE: Nettle-3.5
Magnus Holmgren writes: > But surely common structs and functions are more convenient for > library users, Maybe. Incompatible changes are surely highly inconvenient, but I'd expect separate functions to fit well in most applications. There's no urgency in deleting the old functions, but I'd like to encourage library users to switch. > and the different fixed key size functions all call the same functions > internally, so isn't there a value in keeping the old interface around? Currently, yes, but I think the implementation in x86_64/aesni could be sped up by using separate functions for aes128, aes192 and aes256. To enable that, it's best to have separate functions all the way. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] Curve point decompression
Wim Lewis writes: > Now that 3.5.1 is out, is there a chance this could be looked at? I'd like to have a closer look soon. > On Wed, May 29, 2019 at 01:25:08AM -0700, Wim Lewis wrote: >> I've pushed some work-in-progress to a git repository here: >> https://git.lysator.liu.se/wiml/nettle Is this still the place for the latest version? Not sure in which order to do things. Maybe it will be best to first add the square root routines, with tests, and then add functions for converting between points and octet strings (and related utilities, if needed). One general questions on the setting: Do you expect any of the new functions will be used for secret data (in contrast to public keys or signatures)? If so, we need to be particularly careful with side-channel leaks. >> things that I think are mathematically impossible >> but can't trivially prove. I would consider adding asserts for such conditions, to ensure that the library fails promptly and in a controlled fashion in case assumptions turn out to be wrong. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Dmitry Eremin-Solenikov writes:
>> 2. What should be the behavior for usage like
>>
>>->set_key
>>->set_nonce
>>->update
>>->digest
>>->update
>>->digest
>>
>>with second set_nonce missing?
>>
>>Should it just keep the nonce from the first digest? (Sounds a bit
>>dangerous). Or autoincrement? (That's what umac does, because it's
>>defined in a way to make that more efficient). Or be specified as
>>invalid, triggering asserts whenever it is easy to detect?
>>
>>I think it has to be specified; it will be too confusing if UMAC
>>behaves in one way and GMAC behaves differently.
>
> I'd say that this is an undefined behaviour. So, if one needs fully
> predictable result, he should set nonce each time. For GMAC nonce MUST
> be set each time to a new value. For UMAC one can skip this call. We
> might want to refine this UB later.
I would prefer to have it nailed down. It kind-of defeats the purpose of
a nettle_mac abstraction if code using it is expected to have if (umac)
{ do this } else { do that }.
> Consider other MACs (like Kasumi F8/Snow3G UIA2/ZUC EIA3) which
> require nonce, can have nonce autoincrement, but with complex rules.
Complex how? If it is a common usecase, one could consider to either do
auto-increment always (part of ->digest, like currently done for umac),
or have a separate method increment_nonce or so.
> BTW: I have written a library with 3GPP encryption/integrity
> alogorithms. The library follow closely Nettle interface. I can
> publish it and/or submit into nettle for inclusion. However I am
> completely unsure about patent status and enforcement for those
> algorithms. Do you know if somebody can advice me on this topic?
It's time consuming to research patent status (and usually impossibly to
reach certainty). Maybe you could ask FSF or sfconservancy lawyers, and
say you consider contributing an implementation to GNU Nettle, but I
doubt they have the resources to do a thorough investigation. If you
know the patent holders, you could mail and ask them, or check if
there's any general patent policy for 3GPP members. Reviewing any
licensing terms they offer should be an easier task for FSF lawyers than
a more open-ended patent investigation.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 1/6] Start separating GOST 28147-89 from GOST R 34.11-94
Dmitry Eremin-Solenikov writes: > I can live with the patch in question being left out for now. We can > merge it later. Merged to master now. One more question: The gost28147.h header, do you intend to add any documented functions there soon? Otherwise, might be better to delete that file and move the declarations of gost28147_param_* over to gost28147-internal.h. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Daiki Ueno writes: > From: Daiki Ueno > > The changes from the previous series are: > - remove the global hmac_*_set_key_expanded functions > - leave out set_nonce member if the operation is not supported > > For the latter, I was wondering whether it is better to define a no-op > set_nonce, but given the fact that that the caller nevertheless checks > nonce_size, I chose to make the field blank. I'm a bit uneasy about the set_nonce pointer. It's used only for umac, where nonce use is a bit peculiar with the auto-increment optimization. Would it be ok to leave umac out, and move the definition of nettle_mac from testutils.h as is (except that the comment "other sizes are sometimes possible" on the key_size field seems wrong)? Then nettle_mac is very similar to nettle_hash, one just calls ->set_key instead of ->init, and one can then hash several messages with the same key using a sequence of ->update and ->digest calls. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 1/6] Start separating GOST 28147-89 from GOST R 34.11-94
Dmitry Eremin-Solenikov writes: > Any feedback on v2 of patchset? Looks good, merged onto a branch godthash94cp. Not sure what to do about the MD_UPDATE cleanup, though, maybe we need to revert that one out to not change the abi (unless we decide to do an abi change for other reasons). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 3/6] gosthash94: switch to using MD_UPDATE() macro
Dmitry Eremin-Solenikov writes:
> --- a/gosthash94.h
> +++ b/gosthash94.h
> @@ -87,8 +87,9 @@ struct gosthash94_ctx
> {
>uint32_t hash[8]; /* algorithm 256-bit state */
>uint32_t sum[8]; /* sum of processed message blocks */
> - uint64_t length; /* number of processed bytes */
> - uint8_t message[GOSTHASH94_BLOCK_SIZE]; /* 256-bit buffer for leftovers */
> + uint64_t count; /* Block count */
> + unsigned index; /* Into buffer */
> + uint8_t block[GOSTHASH94_BLOCK_SIZE]; /* 256-bit buffer for leftovers */
> };
> #define gosthash94cp_ctx gosthash94_ctx
This is a nice cleanup, but it's also both an ABI break, right? Since
the size of this struct is changed.
Unfortunate I missed this one when I moved around fields in other hash
contexts prior to the 3.5 release (which was an abi break), probably
because I was guided by the findings of "git grep block".
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 3/4] gcm: move block shifting function to block-internal.h
dbarysh...@gmail.com writes: > From: Dmitry Eremin-Solenikov > > Move GCM's block shift function to block-internal.h. This concludes > moving of all Galois mul-by-2 to single header. I've merged patch 1-3 to the master-updates branch. Thanks! Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 4/4] gcm: drop intermediate GCM_TABLE_BITS == 4 case
dbarysh...@gmail.com writes: > It makes little sense to have intermediate solution with GCM_TABLE_BITS > == 4. One either will use unoptimized case of GCM_TABLE_BITS == 0, or > will switch to fully optimized case (8) as memory usage difference is > quite low between 4 and 8. So drop GCM_TABLE_BITS == 4 support For the const shift_table, the size difference is 32 bytes vs 512 bytes, which may not be a big deal. I'm more concerned with the size of struct gcm_key, 256 bytes vs 4096 bytes. GCM_TABLE_BITS == 4 seems like a reasonable tradeoff if you have an embedded system with little RAM. It's unfortunate that it is poorly tested. It would make some sense with an (abi-breaking) configure flag --enable-small-size to reduce size of various tables, which could then be tested more regularly. Besides gcm, AES and DES use large constant tables of somewhat configurable size, and for ecc there are both constant tables, for ecc_mul_g, and run-time tables for ecc_mul_a. Is there any interest in improving support for low-end embedded devices? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 4/5] block modes: move Galois shifts to block-internal.h
dbarysh...@gmail.com writes:
> From: Dmitry Eremin-Solenikov
>
> Move Galois polynomial shifts to block-internal.h, simplifying common
> code. GCM is left unconverted for now, this will be fixed later.
Thanks for cleaning this up! Some comments below.
> --- a/block-internal.h
> +++ b/block-internal.h
> @@ -90,4 +90,80 @@ block8_xor_bytes (union nettle_block8 *r,
>memxor3 (r->b, x->b, bytes, 8);
> }
>
> +#define LSHIFT_WORD(x) x) & 0x7f7f7f7f7f7f7f7f) << 1) | \
> + (((x) & 0x8080808080808080) >> 15))
> +#define RSHIFT_WORD(x) x) & 0xfefefefefefefefe) >> 1) | \
> + (((x) & 0x0001010101010101) << 15))
Names of these macros should say U64 or UINT64 rather than WORD. And
something to suggest that they're for alien endianness. Maybe
"LSHIFT_ALIEN_UINT64.
And UINT64_C for the constants.
> +/* Galois multiplications by 2:
> + * functions differ in shifting right or left, big- or little- endianness
> + * and by defininy polynom.
> + * r == x is allowed. */
This is a bit complex, perhaps it can be clarified a bit. We have both
the issue of big or little byte order within words. And bit order used
for representating of the polynomial: usually a less significant bit
within a byte represents a coefficient for a smaller power of the
polynomial variable x, but one of the algorithms (I can't recall which
one) uses opposite bit order.
And if I remember correctly, they all use the same polynomial, but due
to bit-order differences, there are two different ways to represent it.
Which of the functions are called with more than one constant for the
poly argument?
And "defining" is misspelled.
> +#if WORDS_BIGENDIAN
> +static inline void
> +block16_lshift_be (union nettle_block16 *dst,
> +const union nettle_block16 *src,
> +uint64_t poly)
> +{
> + uint64_t carry = src->u64[0] >> 63;
> + dst->u64[0] = (src->u64[0] << 1) | (src->u64[1] >> 63);
> + dst->u64[1] = (src->u64[1] << 1) ^ (poly & -carry);
> +}
> +#else /* !WORDS_BIGENDIAN */
There will be less clutter if all code for #if WORDS_BIGENDIAN is
grouped together. And I think I prefer "mulx" rather than "shift"
somewhere in the name, to indicate that it's not a plain shift.
> --- a/cmac.c
> +++ b/cmac.c
> @@ -44,32 +44,16 @@
>
> #include "memxor.h"
> #include "nettle-internal.h"
> -#include "cmac-internal.h"
> #include "block-internal.h"
> #include "macros.h"
>
> /* shift one and XOR with 0x87. */
> -#if WORDS_BIGENDIAN
> -void
> -_cmac128_block_mulx(union nettle_block16 *dst,
> - const union nettle_block16 *src)
> -{
> - uint64_t carry = src->u64[0] >> 63;
> - dst->u64[0] = (src->u64[0] << 1) | (src->u64[1] >> 63);
> - dst->u64[1] = (src->u64[1] << 1) ^ (0x87 & -carry);
> -}
> -#else /* !WORDS_BIGENDIAN */
> -#define LE_SHIFT(x) x) & 0x7f7f7f7f7f7f7f7f) << 1) | \
> - (((x) & 0x8080808080808080) >> 15))
> -void
> +static inline void
> _cmac128_block_mulx(union nettle_block16 *dst,
> const union nettle_block16 *src)
> {
> - uint64_t carry = (src->u64[0] & 0x80) >> 7;
> - dst->u64[0] = LE_SHIFT(src->u64[0]) | ((src->u64[1] & 0x80) << 49);
> - dst->u64[1] = LE_SHIFT(src->u64[1]) ^ (0x8700 & -carry);
> + block16_lshift_be(dst, src, 0x87);
> }
> -#endif /* !WORDS_BIGENDIAN */
I think it's clearer to delete this and similar wrappers.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 3/5] block-internal: add block XORing functions
dbarysh...@gmail.com writes:
> From: Dmitry Eremin-Solenikov
>
> Add common implementations for functions doing XOR over
> nettle_block16/nettle_block8.
I've merged the first two patches. Thanks! Do you know if anyone is using
GCM_TABLE_BITS 4? I've tested that it still works, both before and after
your change, but I don't test it regularly.
> +static inline void
> +block16_xor_bytes (union nettle_block16 *r,
> +const union nettle_block16 *x,
> +const uint8_t *bytes)
> +{
> + memxor3 (r->b, x->b, bytes, 16);
> +}
[...]
> +static inline void
> +block8_xor_bytes (union nettle_block8 *r,
> +const union nettle_block8 *x,
> +const uint8_t *bytes)
> +{
> + memxor3 (r->b, x->b, bytes, 8);
> +}
Not sure these two wrappers are that helpful. Do you have a good
reason to add them?
The rest of the patch looks like a nice consolidation.
> --- a/gcm.c
> +++ b/gcm.c
> @@ -53,16 +53,10 @@
> #include "nettle-internal.h"
> #include "macros.h"
> #include "ctr-internal.h"
> +#include "block-internal.h"
>
> #define GHASH_POLYNOMIAL 0xE1UL
>
> -static void
> -gcm_gf_add (union nettle_block16 *r,
> - const union nettle_block16 *x, const union nettle_block16 *y)
> -{
> - r->u64[0] = x->u64[0] ^ y->u64[0];
> - r->u64[1] = x->u64[1] ^ y->u64[1];
> -}
> /* Multiplication by 010...0; a big-endian shift right. If the bit
> shifted out is one, the defining polynomial is added to cancel it
> out. r == x is allowed. */
> @@ -108,7 +102,7 @@ gcm_gf_mul (union nettle_block16 *x, const union
> nettle_block16 *y)
>for (j = 0; j < 8; j++, b <<= 1)
> {
> if (b & 0x80)
> - gcm_gf_add(, , );
> + block16_xor3(, , );
This and few other calls below can be block16_xor rather than block16_xor3.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Some .stamp files slipped into the tarball
Justus Winter writes: > And the build system I adopted doesn't actually use cp, I just > demonstrated the problem using cp. Therefore, it is not as easy as > using -a instead of -r. > > In any case, I'm just going to delete any .stamp files in my build > process. I would recommend that you either arrange to preserve timestamps, or delete all generated files that make knows how to recreate. Otherwise, the steps performed by make during the build will depend on the order in which the files happened to be copied, which seems brittle. > And I wanted to be a good downstream user and report what I perceived > as a packaging hickup. Thanks. I wasn't aware if this failure mode. I don't see any great solution. It would be nice if one could tell make that there's a dependency chain foo.c --> foo --> bar and that foo (the executable) is unimportant. That should mean that as long as bar is more recent than foo.c, there's no need to remake bar, and no need to remake foo, no matter if foo happens to be out-of-date or non-existent. The stamp file is a workaround, and as you noticed, it's not perfect. Is there a better way? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] cmac: add 64-bit mode CMAC
ni...@lysator.liu.se (Niels Möller) writes: > I've now merged this and the cmac_des3 patch onto a branch "cmac64". And now pushed to master, together with the documentation update. Thanks, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Some .stamp files slipped into the tarball
Justus Winter writes:
> I read the reference, and I don't see how it applies here.
Right, it's a bit different.
> For the
> record, this is the build failure that I'm referring to:
>
> % tar xf nettle-3.5.1.tar.gz
> % cp -r nettle-3.5.1 nettle
> % cd nettle
> % ./configure
> [...]
> % make
> [...]
> f="./`basename rotors.h`"; \
> ./desdata rotors.h > ${f}T; \
> test -s ${f}T && mv -f ${f}T $f
> /bin/sh: 2: ./desdata: not found
This is a bit subtle, and maybe it can be improved. Let me explain how
it's supposed to work.
rotors.h and keymap.h are generated by the desdata program, built from
the desdata.c source file. They're not platform dependent in any way, so
they're distributed with the tarball. When building from the tarball,
there's no need to regenerate them, and the desdata program isn't built.
Now dependencies for this is a bit tricky. One obvious alternative is
rotors.h: desdata
./desdata ...
That has the drawback that it will needlessly build desdata and regenerate the
files when building from a tarball, since the desdata executable
obviously shouldn't be in the tarball. Another alternative is
rotors.h: desdata.c
$(MAKE) desdata
./desdata ...
That breaks make -j, because if rotors.h and keymap.h are regenerated in
parallel, we'll get two processes trying to build and run desdata at the
same time, resulting in spurious errors.
Hence the redirection via desdata.stamp, to ensure that we only have one
process building desdata. And now it seems that results in a failure if
the build directory is in the state that desdata.stamp is newer than
both desdata.c and rotors.h and but ./desdata doesn't exist.
Not sure how to fix that. A workaround is to copy with cp -a, which
ensures that you won't attempt to rebuild *any* of the generated files
in the tarball, including config.h.in and configure. Might also help a
bit to reorder the files in the tarball, but I wouldn't recommend
depending on that.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Rust bindings
Justus Winter writes: > When we started the project, we evaluated cryptographic libraries, and > decided that Nettle would be the best fit for us, even if it involved > creating language bindings first. Looking back after one and a half > years, we're still happy with our choice. So let me express our > gratitude for everyone who is or has been working on Nettle! Thanks! Have you looked at nettle's pgp.h? This code is not really in a useful state. It aims to be able to write out a public RSA key in openpgp format, and doesn't quite succeed at that. Do you think it would be useful with some level of pgp-support in the Nettle library? Regarding the Rust bindings, what's the best place to point other Rust users? https://crates.io/crates/nettle, or https://sequoia-pgp.gitlab.io/nettle-rs/nettle/, or somewhere else? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Some .stamp files slipped into the tarball
Justus Winter writes: > just a small bug report, there are some .stamp files that got included > in the release by accident. I noticed because it caused build problems, > likely only due to the fact that my build process copied the files once, > changing the mtimes in the process. Some stamp files are included intentionally, to avoid precisely that type of problems. See the note on stamp-h.in in the autoconf manual for one well documented example: https://www.gnu.org/software/autoconf//manual/autoconf-2.64/html_node/Automatic-Remaking.html Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: nettle-meta interface for MACs
Daiki Ueno writes:
> This is, however, not usable for HMAC, because Nettle build uses
> -Wcast-function-type and the set_key member has an incompatible type
> with hmac_*_set_key, which requires a key length argument as HMAC allows
> arbitrary key length up to the hash block size.
It's also not directly usable with umac, which takes a nonce (and auto
increment in umac*_digest). Should the generic interface try to
accomodate macs that require a nonce?
> Is there any plan to make it more generic and eventually move it to
> nettle-meta.h? That would be particularly useful in applications
> passing around HMAC functions (e.g., HKDF, deterministic ECDSA).
If we can find a reasonable "generic" interface, yes.
> For example, I'm thinking to use nettle_hash_update_func for set_key and
> provide a wrapper around other MACs which don't take key length,
> something like:
>
> void
> _cmac_aes128_set_key(struct cmac_aes128_ctx *ctx,
> size_t length, const uint8_t *key)
> {
>assert (length == AES128_KEY_LENGTH);
>cmac_aes128_set_key (ctx, length, key);
> }
I would consider doing it the other way around, and define nettle_hmac_*
with fixed key size, for the key sizes used by applications. E.g,
https://tools.ietf.org/html/rfc4253#section-6.4 defines 4 mac algorithms
based on hmac, with the main one being hmac-sha1, with a fixed key size
equal to the digest size of 160 bits.
Is it common to use hmac, without context implying a fix key size ?
Slightly related: HMAC is defined as allowing very long keys, by hashing
the key in case it's larger than the block size (e.g., 512 bits for
hmac-sha1 and hmac-sha256). That seems a bit obscure to me. Are there
any applications or protocols depending on that feature?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] cmac: add 64-bit mode CMAC
Dmitry Eremin-Solenikov writes: > --- /dev/null > +++ b/cmac64.c > @@ -0,0 +1,177 @@ > +/* > + AES-CMAC-128 (rfc 4493) / CMAC-64 I've now merged this and the cmac_des3 patch onto a branch "cmac64". What's an authoritative reference for cmac64 and cmac using des? RFC4493 doesn't seem quite right. Is it NIST SP 800-38B, mentioned in a comment with the tests? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 1/6] Start separating GOST 28147-89 from GOST R 34.11-94
Dmitry Eremin-Solenikov writes:
> Hash function GOST R 34.11-94 (gosthash94) in its compression function
> uses Russian block cipher (GOST 28147-89, Magma). Start separating block
> cipher code from hash function code. For now there is no public
> interface for this cipher, it will be added later.
I'm having an initial look at this, with a few comments.
> --- /dev/null
> +++ b/gost28147.c
> +/*
> + * A macro that performs a full encryption round of GOST 28147-89.
> + * Temporary variables tmp assumed and variables r and l for left and right
> + * blocks.
> + */
> +#define GOST_ENCRYPT_ROUND(key1, key2, sbox) \
> + tmp = (key1) + r; \
> + l ^= (sbox)[0*256 + (tmp & 0xff)] ^ (sbox)[1*256 + ((tmp >> 8) & 0xff)] ^ \
> +(sbox)[2*256 + ((tmp >> 16) & 0xff)] ^ (sbox)[3*256 + (tmp >> 24)]; \
> + tmp = (key2) + l; \
> + r ^= (sbox)[0*256 + (tmp & 0xff)] ^ (sbox)[1*256 + ((tmp >> 8) & 0xff)] ^ \
> +(sbox)[2*256 + ((tmp >> 16) & 0xff)] ^ (sbox)[3*256 + (tmp >> 24)];
This code is just moved around in this patch, but I'd like to note that
it's preferable to always wrap function-like macros like this in do { ... }
while (0), and when used terminate with ;. And avoid using surrounding
variables; r and l could be macro arguments, and tmp (with some likely
unique prefix) could be a local in the do { ... } while block.
> --- /dev/null
> +++ b/gost28147.h
> @@ -0,0 +1,63 @@
> +struct gost28147_param
> +{
> + uint32_t sbox[4*256];
> +};
Why change to a flat array, and not keep it as
uint32_t sbox[4][256];
?
> +extern const struct gost28147_param gost28147_param_test_3411;
I find "test" in the name a bit odd. Is there a reason for that? And
declaration should probably not be in an installed header file, but in
gost-internal.h or so.
> +/* Internal interface for use by GOST R 34.11-94 */
> +void gost28147_encrypt_simple (const uint32_t *key, const uint32_t *sbox,
> + const uint32_t *in, uint32_t *out);
Same here: if internal, shouldn't be in an installed header file. And
"simple" looks a bit odd.
Should the sbox argument be of type const gost28147_param * ?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] cmac: add 64-bit mode CMAC
Dmitry Eremin-Solenikov writes:
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> cmac.c | 125 -
> cmac.h | 69 +++
> nettle-types.h | 6 +++
> 3 files changed, 199 insertions(+), 1 deletion(-)
>
> diff --git a/cmac.c b/cmac.c
> index 70ce8132d9d1..36ad8e58e45e 100644
> --- a/cmac.c
> +++ b/cmac.c
> @@ -1,9 +1,10 @@
> /*
> - AES-CMAC-128 (rfc 4493)
> + AES-CMAC-128 (rfc 4493) / CMAC-64
> Copyright (C) Stefan Metzmacher 2012
> Copyright (C) Jeremy Allison 2012
> Copyright (C) Michael Adam 2012
> Copyright (C) 2017, Red Hat Inc.
> + Copyright (C) 2019, Dmitry Eremin-Solenikov
>
> This file is part of GNU Nettle.
>
> @@ -57,6 +58,15 @@ _cmac128_block_mulx(union nettle_block16 *dst,
>dst->u64[0] = (src->u64[0] << 1) | (src->u64[1] >> 63);
>dst->u64[1] = (src->u64[1] << 1) ^ (0x87 & -carry);
> }
> +
> +static void
> +block_mulx8(union nettle_block8 *dst,
> + const union nettle_block8 *src)
> +{
> + uint64_t carry = src->u64 >> 63;
> +
> + dst->u64 = (src->u64 << 1) ^ (0x1b & -carry);
> +}
> #else /* !WORDS_BIGENDIAN */
> #define LE_SHIFT(x) x) & 0x7f7f7f7f7f7f7f7f) << 1) | \
> (((x) & 0x8080808080808080) >> 15))
> @@ -68,6 +78,15 @@ _cmac128_block_mulx(union nettle_block16 *dst,
>dst->u64[0] = LE_SHIFT(src->u64[0]) | ((src->u64[1] & 0x80) << 49);
>dst->u64[1] = LE_SHIFT(src->u64[1]) ^ (0x8700 & -carry);
> }
Patch looks nice, thanks! Is any of the implementation shared with
cmac128? I think it would be nice to move it to a separate source file
cmac64.c. Sharing the cmac.h header file is fine.
BTW, I'm sorry for the duplicated effort on nettle_block16 w; I'm
traveling and online only sporadically, so I gave it a try without being
up to date with your work.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/3] gcm: drop w field from nettle_block16
Dmitry Eremin-Solenikov writes: > "unsigned long w" comes from the time when Nettle didn't use uint64_t. > It is unused now and thus can be dropped. I've done something very similar on the block16-refactor branch. > + r->u64[0] = (x->u64[0] >> 1) ^ (mask & (GHASH_POLYNOMIAL << 56)); I've found this needs to be (uint64_t) GHASH_POLYNOMIAL << 56. Otherwise tests fail when I cross compile for (32-bit) mips and run under qemu. I'm also trying to move helper functions (most or all should be inline) to block16-internal.h. Next, I'm looking into unifying the various shift operations. It seems we have the following variants: Big-endian left shift: cmac, eax, polynomial 0x87 Little-endian left shift: xts, polynomial 0x87 Big-endian right shift: gcm, polynomial 0xE1 (bit-reverse of 0x87) If I understand it correctly after a quick look (long since I looked at GCM in detail), its represents the polynomials with a peculiar bit-order where what's otherwise the least significant bit represents the coefficient of the highest power of x. The multiplication is kind-of invariant under bit-reversal, but I'm not sure if it's possible to rearrange it to use a different bit order without explicit bit reversal of the input. At least, not an easy change. I'm thinking of some shared macros or inline functions to abstract the left shift operations, say block16_mulx_be, block16_mulx_le. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] nettle-types: drop w field from nettle_block16
Dmitry Eremin-Solenikov writes: > Hmm. This patch has to wait a bit, sent it without actual testing. > nettle_block16.w is used by eax (easy to copy with) and gcm > (might need performance checks on 32-bit architectures). I would expect that using the uint64_t field is as efficient (or better, if compilers do it really well), but I haven't checked the generated code on 32-bit archs. Can we delete the w field from the union without considering it an abi break? I'd expect size and alignment of the union to be unchanged on all but the most obscure architectures. If not, that part of the change has to wait. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/4] cmac: add 64-bit mode CMAC
Dmitry Eremin-Solenikov writes:
> +union nettle_block8
> +{
> + uint8_t b[8];
> + unsigned long w[8 / sizeof(unsigned long)];
> + uint64_t u64;
> +};
The "unsigned long w" seems unneeded (in nettle_block16, it could
also be retired; it's from a time when Nettle didn't use uint64_t).
Maybe one could do without this union and simply use uint64_t, but then
one would need some casts to (uint8_t *). So a union may be clearer.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 1/4] Move MAC testing code to generic place from cmac-test
Dmitry Eremin-Solenikov writes:
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> testsuite/cmac-test.c | 100 +++---
> testsuite/testutils.c | 64 +++
> testsuite/testutils.h | 6 +++
> 3 files changed, 96 insertions(+), 74 deletions(-)
>
> diff --git a/testsuite/cmac-test.c b/testsuite/cmac-test.c
> index 31662d1b6c1b..b1d4aa30dfbe 100644
> --- a/testsuite/cmac-test.c
> +++ b/testsuite/cmac-test.c
> @@ -2,83 +2,35 @@
> #include "nettle-internal.h"
> #include "cmac.h"
>
> +const struct nettle_mac nettle_cmac_aes128 =
> +{
> + "CMAC-AES128",
Names are usually lowercase, but doesn't really matter for the tests.
I'm merging this patch now, currently on master-updates for testing by
the gitlab ci.
I've had a look at also updating the hmac and umac tests, but that
wasn't as easy as I hoped. For hmac, the variable key size doesn't fit
the struct nettle_mac. For umac, key size is fixed, but one also has a
nonce and nonce auto-increment.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Add check for ECC at point 0
Simo Sorce writes: > On Wed, 2019-05-15 at 10:48 -0400, Simo Sorce wrote: >> On Wed, 2019-05-15 at 11:42 +0200, Niels Möller wrote: >> > Simo Sorce writes: >> > >> > > Attached find patch that adds points checks to the ECDH test case. >> > > Let me know if that's ok or if you prefer a whole new test. Merged now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: SIV-CMAC
Nikos Mavrogiannopoulos writes: > I prefer the second option because I think the zero nonce variant > requires a disproportionate, to its usefullness and use, discussion to > define the "right" semantics. Merged siv-mode to the master branch now. Does it look right to you? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Changes after 3.5.1
Dmitry Eremin-Solenikov writes: > I have several patch series that were sitting in my local gost tree. > Most of them were posted to this mailing list for review with little > to no feedback. > - CMAC-64 support (together with CMAC-TDES for testing). > - Changes to GOST R 34.11-94 (gosthash94) code > - GOST 28147-89/Magma 64-bit cipher (depend on gosthash94 changes) > - Additional cipher modes required for full GOST 28147-89 support > - Streebog hash algorithm (GOST R 34.11-2012) > - Several GOST curves (2 for now, other require changes to ecc backend) > - GOST ECC-based digital signature scheme > - GOST ECC-based key agreement > - small chunks of additional support code Except for the last one (not sure what those changes are), this looks like a reasonable order. For the ecc things, I think I'd give the ed448 changes higher priority. Can you resend links for the first two or thee changes, or resend latest patches? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
ANNOUNCE: Nettle-3.5.1
There was a packaging problem with the Nettle-3.5 release of yesterday, breaking certain x86_64 configurations. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The corrected release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.5.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.5.1.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.5.1.tar.gz Regards, /Niels NEWS for the Nettle 3.5.1 release The Nettle-3.5.1 corrects a packaging mistake in Nettle-3.5. The new directory x86_64/sha_ni were missing in the tar file, breaking x86_64 builds with --enable-fat, and producing worse performance than promised for builds with --enable-x86-sha-ni. Also a few unused in-progress assembly files were accidentally included in the tar file. These problems are corrected in Nettle-3.5.1. There are no other changes, and also the library version numbers are unchanged. NEWS for the Nettle 3.5 release This release adds a couple of new features and optimizations, and deletes or deprecates a few obsolete features. It is *not* binary (ABI) compatible with earlier versions. Except for deprecations listed below, it is intended to be fully source-level (API) compatible with Nettle-3.4.1. The shared library names are libnettle.so.7.0 and libhogweed.so.5.0, with sonames libnettle.so.7 and libhogweed.so.5. Changes in behavior: * Nettle's gcm_crypt will now call the underlying block cipher to process more than one block at a time. This is not a change to the documented behavior, but unfortunately breaks assumptions accidentally made in GnuTLS, up to and including version 3.6.1. New features: * Support for CFB8 (Cipher Feedback Mode, processing a single octet per block cipher operation), contributed by Dmitry Eremin-Solenikov. * Support for CMAC (RFC 4493), contributed by Nikos Mavrogiannopoulos. * Support for XTS mode, contributed by Simo Sorce. Optimizations: * Improved performance of the x86_64 AES implementation using the aesni instructions. Gives a large speedup for operations processing multiple blocks at a time (including CTR mode, GCM mode, and CBC decrypt, but *not* CBC encrypt). * Improved performance for CTR mode, for the common case of 16-byte block size. Pass more data at a time to underlying block cipher, and fill the counter blocks more efficiently. Extension to also handle GCM mode efficiently contributed by Nikos Mavrogiannopoulos. * New x86_64 implementation of sha1 and sha256, for processors supporting the sha_ni instructions. Speedup of 3-5 times on affected processors. * Improved parameters for the precomputation of tables used for ecc signatures. Roughly 10%-15% speedup of the ecdsa sign operation using the secp_256r1, secp_384r1 and secp_521r1 curves, and 25% speedup of ed25519 sign operation, benchmarked on x86_64. Table sizes unchanged, around 16 KB per curve. * In ARM fat builds, automatically select Neon implementation of Chacha, where possible. Contributed by Yuriy M. Kaminskiy. Deleted features: * The header file des-compat.h and everything declared therein has been deleted, as announced earlier. This file provided a subset of the old libdes/ssleay/openssl interface for DES and triple-DES. DES is still supported, via the functions declared in des.h. * Functions using the old struct aes_ctx have been marked as deprecated. Use the fixed key size interface instead, e.g., struct aes256_ctx, introduced in Nettle-3.0. * The header file nettle-stdint.h, and corresponding autoconf tests, have been deleted. Nettle now requires that the compiler/libc provides . Miscellaneous: * Support for big-endian ARM systems, contributed by Michael Weiser. * The programs aesdata, desdata, twofishdata, shadata and gcmdata are no longer built by default. Makefile improvements contributed by Jay Foad. * The "example" program examples/eratosthenes.c has been deleted. * The contents of hash context structs, and the deprecated aes_ctx struct, have been reorganized, to enable later optimizations. -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. signature.asc Description: PGP
Re: [PATCH 1/3] build: allow overriding the debug flags
Alon Bar-Lev writes: > Which way do you prefer to avoid adding this flag? having environment > variable or --disable-xxx? You've brought up two different issues. For CFLAGS, I agree it could be improved. Not sure what's the best way is, but the main thing is to let CFLAGS be a user setting, following the coding standard. There could be an option to enable or disable the maintainer's (i.e. my) choice of additional warning flags. The libdir issue is a different thing. The automatic hack only affects the *default* libdir, and is already overridable with the standard option --libdir=... In that case, I see little point in a new special option to disable the current behavior. What might make sense, if you convince me that the automatic selection really is an inappropriate default, is to enable it explicitly by using --libdir=auto. And I'd still like to know if the there's been any related multiarch improvements in autoconf's default behavior recently. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: ANNOUNCE: Nettle-3.5
ni...@lysator.liu.se (Niels Möller) writes:
> Nikos Mavrogiannopoulos writes:
>
>> The x86_64/sha_ni directory is not included in the distribution, and
>> thus compilation fails when --enable-fat is provided. I update my
>> previous patch to add `make distcheck` to include enable-fat, so that
>> missing files from distribution are caught earlier.
>
> Ouch. I'll have to make an updated release later today or tomorrow.
Below is the patch I'm considering, as well as the diff to the file list
of the resulting tar file (I've also moved away two unfinished and
uncommitted files from the x86_64 directory, which were unintentionally
picked up by make dist).
I'm not changing the library versions, since any configuration of 3.5
that can be built succesfully will be completely compatible with 3.5.1,
with the only difference being that x86_64 builds with
--enable-x86-sha-ni will be a lot faster with 3.5.1.
Any last minute comments appreciated. I intend to do the updated release
in a few hours, since I'm about to leave for summer vacation.
Regards,
/Niels
diff --git a/ChangeLog b/ChangeLog
index c3d298c7..32a3e3ba 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2019-06-26 Niels Möller
+ * configure.ac: Update version number to 3.5.1.
+
+ * Makefile.in (distdir): Add x86_64/sha_ni to list of distributed
+ directories.
+
* Released nettle-3.5.
2019-06-25 Niels Möller
diff --git a/Makefile.in b/Makefile.in
index a6b8ffd6..537e97d1 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -586,7 +586,7 @@ distdir: $(DISTFILES)
fi ; \
done
set -e; for d in sparc32 sparc64 x86 \
- x86_64 x86_64/aesni x86_64/fat \
+ x86_64 x86_64/aesni x86_64/sha_ni x86_64/fat \
arm arm/neon arm/v6 arm/fat ; do \
mkdir "$(distdir)/$$d" ; \
find "$(srcdir)/$$d" -maxdepth 1 '(' -name '*.asm' -o -name '*.m4'
')' \
diff --git a/NEWS b/NEWS
index 622377f3..5e94c893 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,16 @@
+NEWS for the Nettle 3.5.1 release
+
+ The Nettle-3.5.1 corrects a packaging mistake in Nettle-3.5.
+ The new directory x86_64/sha_ni were missing in the tar file,
+ breaking x86_64 builds with --enable-fat, and producing worse
+ performance than promised for builds with --enable-x86-sha-ni.
+ Also a few unused in-progress assembly files were accidentally
+ included in the tar file.
+
+ These problems are corrected in Nettle-3.5.1. There are no
+ other changes, and also the library version numbers are
+ unchanged.
+
NEWS for the Nettle 3.5 release
This release adds a couple of new features and optimizations,
diff --git a/configure.ac b/configure.ac
index 00d2bf5d..3547cae4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl -*- mode: shell-script; sh-indentation: 2; -*-
dnl Process this file with autoconf to produce a configure script.
-AC_INIT([nettle], [3.5], [nettle-bugs@lists.lysator.liu.se])
+AC_INIT([nettle], [3.5.1], [nettle-bugs@lists.lysator.liu.se])
AC_PREREQ(2.61)
AC_CONFIG_SRCDIR([arcfour.c])
# Needed to stop autoconf from looking for files in parent directories.
--- /dev/fd/63 2019-06-26 19:24:14.688527655 +0200
+++ /dev/fd/62 2019-06-26 19:24:14.692527654 +0200
@@ -123,7 +123,6 @@
x86_64/aes-decrypt-internal.asm
x86_64/ecc-256-redc.asm
x86_64/salsa20-crypt.asm
-x86_64/ecc-25519-modp-mul.asm
x86_64/md5-compress.asm
x86_64/gcm-hash8.asm
x86_64/sha256-compress.asm
@@ -157,13 +156,15 @@
x86_64/sha512-compress.asm
x86_64/chacha-core-internal.asm
x86_64/ecc-224-modp.asm
+x86_64/sha_ni/
+x86_64/sha_ni/sha256-compress.asm
+x86_64/sha_ni/sha1-compress.asm
x86_64/salsa20.m4
x86_64/poly1305-internal.asm
x86_64/serpent-decrypt.asm
x86_64/umac-nh.asm
x86_64/memxor.asm
x86_64/ecc-25519-modp.asm
-x86_64/sha1-compress-sse.asm
x86_64/serpent-encrypt.asm
x86_64/ecc-521-modp.asm
camellia-absorb.c
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/3] build: add --disable-libdir-abi-detection
Dmitry Eremin-Solenikov writes:
> What about just checking if libdir was overwritten via argument and not
> touching it if it was the case? Will that work for you?
That's exactly how it has worked ever since this detection was added
back in 2010. Which is why I suggest that packagers who find that the
automatic detection is inappropriate simply use the standard --libdir=
command line option.
With the only caveat that since I didn't find a way to really check if
--libdir was provided or not, I compare $libdir to the default value,
the literal string '${exec_prefix}/lib', which is somewhat unlikely to
be used on the command line.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/3] build: add --disable-libdir-abi-detection
Jeffrey Walton writes: >> From which autoconf version? I'd be happy to require a recent autoconf >> and drop this code if it's no longer needed. When this hack was added, >> it was the case that one or the other of > > Please NO. Don't require an updated Autotools version. Huh? The configure script is included in the release tarball. You *don't* need to even have autoconf installed to build the library. That's half of the point of using autoconf at all. Requirement on autoconf only matters for those who want to modify configure.ac, or build from a git repo. (And also, please don't use the term "autotools" if you want to say anything specific; autotools is a very loose term refering to a couple of very different tools each with their own particular quirks). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/3] build: add --disable-libdir-abi-detection
Alon Bar-Lev writes:
> You should not do this in autoconf, autoconf is already detecting
> everything that is required,
From which autoconf version? I'd be happy to require a recent autoconf
and drop this code if it's no longer needed. When this hack was added,
it was the case that one or the other of
./configure CC='gcc -m32' && make && make install
or
./configure CC='gcc -m64' && make && make install
would install library files in the wrong directory, overwriting and
damaging any correctly installed library previously installed in that
place. On some systems, even
./configure && make && make install
would cause damage. Systems affected included any x86_64 gnu/linux
system that (i) adhered to the linux hierarchy standard with 32-bit x86
libraries in /usr/local/lib (including gentoo, but not debian), and had
a gcc installation defaulting to generating code for x86_64 (which I'd
guess gentoo did too).
So the libdir detection is intended to help the user to not shot
him/herself in the foot.
I don't know what current gentoo does. Debian's way of doing multiarch
makes a lot of sense to me. You can then configure any autoconfed
library, including nettle, with something like
--prefix=/usr --libdir='${prefix}/lib/${host}'
and nettle's special libdir default is not used.
Does recent autoconf do anything like that by default?
> Having said that, and to avoid backward compatibility, I would like to
> add a switch to disable this behavior completely and relay on the
> default logic of autoconf as expected.
Would it make sense to have this automatic detection apply only when
also the prefix is the default /usr/local? (Unfortunately, I don't know
how a configure script can find out authoritatively if --prefix or
--libdir were present on the command line, which is why I compare libdir
to the default value instead.
And I really don't understand why you'd prefer a nettle specific
--disable-... argument over the GNU standard --libdir=/usr/lib/whatever.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 1/3] build: allow overriding the debug flags
Alon Bar-Lev writes: > I do not understand... In practice a package should not add by itself > optimization or debug flags without consent (some --enable- argument), > the fact that nettle is doing that is unexpected... I'm open to discuss how to deal with CFLAGS. Currently, Nettle sets -ggdb3, various warning flags (if compiling with gcc), and it kind-of adds -fPIC, but via different autoconf and make variables. I think GNU standard is to use something like -g -O by default. As a developer, I find it convenient to have stricter warning flags and more debug info by default, but that could be tied to an explicit configure argument and disabled by default. When suggesting improvements, please consider recommendations in the GNU coding standards. Also keep in mind that ./configure defaults are intended primarily to make life easy for the user that runs ./configure manually, perhaps to try out a modification of her own. If you have a packaging framework that runs configure for you, it's expected that package configuration needs to add a couple of explicit arguments to override the defaults. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 2/3] build: add --disable-libdir-abi-detection
Alon Bar-Lev writes:
> opt out overriding the libdir, in most cases downstream distribution is
> providing the correct one
>
> Signed-off-by: Alon Bar-Lev
> ---
> configure.ac | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 379c021c..fb0b3c8c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -339,7 +339,11 @@ case "$host_cpu" in
> ;;
> esac
>
> -if test "x$ABI" != xstandard ; then
> +AC_ARG_ENABLE(libdir-abi-detection,
> + AC_HELP_STRING([--disable-libdir-abi-detection], [Disable libdir ABI
> detection]),,
> + [enable_libdir_abi_detection=yes])
> +
> +if test "x$ABI" != xstandard -a "x${enable_libdir_abi_detection}" = "yes" ;
> then
>AC_MSG_NOTICE([Compiler uses $ABI-bit ABI. To change, set CC.])
>if test "$libdir" = '${exec_prefix}/lib' ; then
> # Try setting a better default
Isn't it clearer to use
./configure --prefix=/usr --libdir=/usr/lib
rather than
./configure --prefix=/usr --disable-libdir-abi-detection
The above if test "$libdir" = '${exec_prefix}/lib' disables the
automatic choice if you use --libdir=foo, with foo different from the
magic string '${exec_prefix}/lib'.
Alon Bar-Lev writes:
> Signed-off-by: Alon Bar-Lev
> ---
> configure.ac | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index fb0b3c8c..5f2bf170 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -654,13 +654,13 @@ case "$host_os" in
> LIBNETTLE_FORLINK=libnettle.dylib
> LIBNETTLE_SONAME='libnettle.$(LIBNETTLE_MAJOR).dylib'
> LIBNETTLE_FILE='libnettle.$(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR).dylib'
> -LIBNETTLE_LINK='$(CC) $(CFLAGS) -dynamiclib $(LDFLAGS) -install_name
> ${libdir}/$(LIBNETTLE_SONAME) -compatibility_version $(LIBNETTLE_MAJOR)
> -current_version $(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR)'
> +LIBNETTLE_LINK='$(CC) $(CFLAGS) -dynamiclib $(LDFLAGS) -install_name
> $(libdir)/$(LIBNETTLE_SONAME) -compatibility_version $(LIBNETTLE_MAJOR)
> -current_version $(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR)'
> LIBNETTLE_LIBS=''
I don't understand this change. $(foo) and ${foo} have the same meaning
in make (and this is quoted from the shell). A think it's an improvement
to change ${} to $() here, for consistency with other nerby make
references, but I take it you intend to do something more than an
aesthetic change? Am I missing something?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 1/3] build: allow overriding the debug flags
Alon Bar-Lev writes: > In Gentoo and probably other downstream distributions we let package > management to manage the flags This is a bit tricky. One can already pass CFLAGS= to configure. But I think the intention is that should override configure's automatic selection of flags (I haven't tested that though). But usually, one wants the package's configure have some say, and e.g., enable warnings that are expected to be silent. So I'd rather have something more general like APPEND_CFLAGS added after CFLAGS to make it possible to override selected flags, and with some consistency with other packages using autoconf. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: ANNOUNCE: Nettle-3.5
Alon Bar-Lev writes: > I sent three patches to cleanup our gentoo downstream patches, can you > please consider them for the release so we have zero patching? Not for this release, sorry. I'll send comments on the patches separately. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: ANNOUNCE: Nettle-3.5
Nikos Mavrogiannopoulos writes: > The x86_64/sha_ni directory is not included in the distribution, and > thus compilation fails when --enable-fat is provided. I update my > previous patch to add `make distcheck` to include enable-fat, so that > missing files from distribution are caught earlier. Ouch. I'll have to make an updated release later today or tomorrow. Thanks for finding it quickly. I've run at least a dozen of different tests on the rc1 tarball, but apparently none with x86_64 --enable-fat :-( And problem is of course not limited to fat builds, it's just that --enable-fat happens to make it visible at compile time. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
nettle-3.5rc1
Hi, I've been talking about release for quite some time, without getting to it. I think the current state is pretty good, and I'd like to get the release out before summer vacations. I know there are several very desirable features being worked on, and I'm very happy about that, but release line has to be drawn somewhere. So I've prepared a nettle-3.5rc1 tarball, https://www.lysator.liu.se/~nisse/archive/nettle-3.5rc1.tar.gz, and there's a corresponding "nettle_3.5rc1" tag in the repository. I'll run tests on some of the gmp and gcc test machines. I think I'll get coverage for x86_64, mips, arm, power, maybe sparc. These machines mainly free operating systems, gnu/linux or freebsd. Help with testing on additional systems is highly appreciated, in particular testingon android and on any proprietary OS:es of interest. Please also review the NEWS file, if there's anything NEWS-worthy that I have missed, speak up. Or if there are some additional improvements that really ought to get into the 3.5 release. I aim to have the release happen in a week or two. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] Fix some typos in the documentation
Wim Lewis writes: > nettle.texinfo | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) Thanks, applied. The patch has some long lines broken, which had to be fixed for it to apply correctly. For mailers that don't like long lines, sending patches as text attachments is more robust. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: curve448 branch
Dmitry Eremin-Solenikov writes:
> I'm still playing around HMAC/digest refactoring, but I'm not happy with the
> way code looks in my tree.
Below patch is a faitly simple way to do it. It adds internal functions
with a state_size argument, uses that when saving and restoring state,
and switches hmac_md5 to a new smaller context struct.
Key change is defining
struct hmac_md5_ctx
{
/* Same as struct md5_ctx without the buffer. */
struct {
uint32_t state[_MD5_DIGEST_LENGTH];
uint64_t count; /* Block count */
unsigned index; /* Into buffer */
} outer, inner;
struct md5_ctx state;
};
It would be a bit cleaner to not include count and index in this struct.
hmac_md5_digest can know that when resetting the state, we always have
index == 0 and count == 1. But the general _hmac_digest doesn't know how
to write those fields.
One could consider rewriting hmac_md5_digest without using _hmac_digest.
Or rethink what helpers really are needed to implement hmac_foo_set_key
and hmac_foo_digest without too much duplication.
If one looks closer, the hmac_set_key has code for the specal case to do
an initial hashing the key if key_size > block_size, but except for
that, it's really wants to invoke the compression function.
I imagine what you're working on is quite similar?
Regards,
/Niels
diff --git a/hmac-internal.h b/hmac-internal.h
new file mode 100644
index ..ee486dab
--- /dev/null
+++ b/hmac-internal.h
@@ -0,0 +1,51 @@
+/* hmac-internal.h
+
+ HMAC message authentication code (RFC-2104).
+
+ Copyright (C) 2001, 2002, 2019 Niels Möller
+
+ This file is part of GNU Nettle.
+
+ GNU Nettle is free software: you can redistribute it and/or
+ modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+ or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+ or both in parallel, as here.
+
+ GNU Nettle is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received copies of the GNU General Public License and
+ the GNU Lesser General Public License along with this program. If
+ not, see http://www.gnu.org/licenses/.
+*/
+
+#ifndef NETTLE_HMAC_INTERNAL_H_INCLUDED
+#define NETTLE_HMAC_INTERNAL_H_INCLUDED
+
+/* Namespace mangling */
+#define _hmac_set_key _nettle_hmac_set_key
+#define _hmac_digest _nettle_hmac_digest
+
+void
+_hmac_set_key(void *outer, void *inner, size_t state_size,
+ void *ctx, const struct nettle_hash *hash,
+ size_t length, const uint8_t *key);
+
+void
+_hmac_digest(const void *outer, const void *inner, size_t state_size,
+void *ctx, const struct nettle_hash *hash,
+size_t length, uint8_t *digest);
+
+#endif /* NETTLE_HMAC_H_INCLUDED */
diff --git a/hmac-md5.c b/hmac-md5.c
index a27e64f6..e0da397c 100644
--- a/hmac-md5.c
+++ b/hmac-md5.c
@@ -35,13 +35,24 @@
# include "config.h"
#endif
+#include
+
#include "hmac.h"
+#include "hmac-internal.h"
+
+#define MIN(a, b) ((a) < (b) ? (a) : (b))
+
+/* Padding may be different in struct md5_ctx and struct hmac_md5_ctx,
+ so use the smallest one when saving and restoring state. */
+#define MD5_STATE_SIZE MIN(sizeof(((struct hmac_md5_ctx *)NULL)->outer), \
+ offsetof(struct md5_ctx, block))
void
hmac_md5_set_key(struct hmac_md5_ctx *ctx,
size_t key_length, const uint8_t *key)
{
- HMAC_SET_KEY(ctx, _md5, key_length, key);
+ _hmac_set_key(>outer, >inner, MD5_STATE_SIZE,
+ >state, _md5, key_length, key);
}
void
@@ -55,5 +66,7 @@ void
hmac_md5_digest(struct hmac_md5_ctx *ctx,
size_t length, uint8_t *digest)
{
- HMAC_DIGEST(ctx, _md5, length, digest);
+ _hmac_digest(>outer, >inner, MD5_STATE_SIZE,
+ >state, _md5,
+ length, digest);
}
diff --git a/hmac.c b/hmac.c
index 6ac5e11a..318de8a2 100644
--- a/hmac.c
+++ b/hmac.c
@@ -2,7 +2,7 @@
HMAC message authentication code (RFC-2104).
- Copyright (C) 2001 Niels Möller
+ Copyright (C) 2001, 2019 Niels Möller
This file is part of GNU Nettle.
@@ -42,6 +42,7 @@
#include "hmac.h"
+#include "hmac-internal.h"
#include "memxor.h"
#include "nettle-internal.h"
@@ -49,15 +50,15 @@
#define OPAD 0x5c
void
-hmac_set_key(void *outer, void *inner, void *state,
-const struct nettle_hash *hash,
-size_t key_length, const uint8_t *key)
+_hmac_set_key(void *outer
Re: siv and cmac
ni...@lysator.liu.se (Niels Möller) writes: > I think the siv code could benefit from a funtion to create a cmac > digest in one step, without the update/digest split and the intermediate > buffer. That would be something like > > cmac128_message(const struct cmac128_key *key, const void *cipher, > nettle_crypt_func *encrypt, > size_t digest_length, uint8_t *digest, > size_t message_length, const uint8_t *message); I haven't added a function like this, but I've now done the changes needed for const context to the siv_*_message functions. For CMAC, the lowest-level functions now take cmac128_key and cmac128_ctx as separate arguments, the former const where appropriate. These changes pushed to master, and it's similar to how gcm is done. I then merged these changes into the siv-mode branch, and updated it accordingly. The _siv_s2v function now takes a const struct cmac128_key argument, and uses a local struct cmac128_ctx with _init, _update, _digest to process the strings with cmac. This enables use of const further up the call chain. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: siv and cmac
Nikos Mavrogiannopoulos writes:
>> Then the key need to be taken out from the cmac128_ctx. I'm trying that
>> out, on the branch cmac-layout. Patch below. What do you think?
>
> Do you see significant performance benefits?
Main benefit is that it makes it possible to make the context argument
to siv_cmac_aes128_encrypt_message and similar functions const.
With a const context, one can, e.g., create a single siv_cmac_aes128_ctx
instance, call the _set_key method once, and then share it between
multiple threads processing messages independently.
With the current code (on the siv-mode branch), _siv_s2v uses parts of
the context struct as working storage for cmac128_update, instead of
using local temporaries. This clobbering of the context is a side effect
with no benefit to the caller.
If we can change
#define SIV_CMAC_CTX(type) { struct CMAC128_CTX(type) siv_cmac; type
siv_cipher; }
to
#define SIV_CMAC_CTX(type) { struct cmac128_key siv_cmac; type siv_cipher; }
then only the _set_key method needs to modify this context.
> Being consistent in hashing/MAC APIs is also a benefit for the library
> and I think the change should be balanced against that.
It's not necessarily a change to the advertised cmac api (the new struct
cmac128_key stays inside struct cmac128_ctx, and applications are not
expected to depend on the details of the context struct), but it would
be a small api/abi break, which is why I'd prefer to make the change
before we make the release including the new cmac code.
At least the specific functions, cmac_aes*, should stay unchanged, for
consistency with other macs.
For the general ones, cmac128_set_key, _update, _digest, maybe they
should take a separate cmac128_key argument, and maybe be demoted to
internal for now? For siv, we would need some variant of cmac_set_key
function that takes only a cmac128_key argument, not a cmac128_ctx, and
the new cmac128_message. These could be internal or public.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Does SHA-1 switch to accelerated automatically?
Jeffrey Walton writes: > Does SHA-1 switch to hardware acceleration for x86 and ARMv8 > automatically? Or is a different call required? If Nettle is configured with --enable-fat, choice of assembly routines is done at runtime. Otherwise, it's a compile-time choice. Regarding sha1, development version (to be nettle-3.5) can use sha_ni instructions on x86_64, for both sha1 and sha256. There isn't yet any assembly code for ARMv8. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
siv and cmac
I think the siv code could benefit from a funtion to create a cmac
digest in one step, without the update/digest split and the intermediate
buffer. That would be something like
cmac128_message(const struct cmac128_key *key, const void *cipher,
nettle_crypt_func *encrypt,
size_t digest_length, uint8_t *digest,
size_t message_length, const uint8_t *message);
Then the key need to be taken out from the cmac128_ctx. I'm trying that
out, on the branch cmac-layout. Patch below. What do you think?
Regards,
/Niels
commit 9b41e3b82b567abb68c1b7fc3b1e6b1a4ed87b26
Author: Niels Möller
Date: 2019-06-01 10:30:29 +0200
New struct cmac128_key.
diff --git a/ChangeLog b/ChangeLog
index 53cdc41d..a7a4355f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2019-06-01 Niels Möller
+
+ * cmac.h (struct cmac128_key): New struct.
+ * cmac.h (struct cmac128_ctx): Use struct cmac128_key.
+ * cmac.c (cmac128_set_key, cmac128_digest): Update accordingly.
+
2019-05-12 Niels Möller
Delete old libdes/openssl compatibility interface.
diff --git a/cmac.c b/cmac.c
index ed3b5eb8..07d805f3 100644
--- a/cmac.c
+++ b/cmac.c
@@ -83,8 +83,8 @@ cmac128_set_key(struct cmac128_ctx *ctx, const void *cipher,
/* step 1 - generate subkeys k1 and k2 */
encrypt(cipher, 16, L->b, const_zero);
- block_mulx(>K1, L);
- block_mulx(>K2, >K1);
+ block_mulx(>key.K1, L);
+ block_mulx(>key.K2, >key.K1);
}
#define MIN(x,y) ((x)<(y)?(x):(y))
@@ -148,11 +148,11 @@ cmac128_digest(struct cmac128_ctx *ctx, const void
*cipher,
if (ctx->index < 16)
{
ctx->block.b[ctx->index] = 0x80;
- memxor(ctx->block.b, ctx->K2.b, 16);
+ memxor(ctx->block.b, ctx->key.K2.b, 16);
}
else
{
- memxor(ctx->block.b, ctx->K1.b, 16);
+ memxor(ctx->block.b, ctx->key.K1.b, 16);
}
memxor3(Y.b, ctx->block.b, ctx->X.b, 16);
diff --git a/cmac.h b/cmac.h
index 6d107982..9d972ea5 100644
--- a/cmac.h
+++ b/cmac.h
@@ -55,18 +55,22 @@ extern "C" {
#define cmac_aes256_update nettle_cmac_aes256_update
#define cmac_aes256_digest nettle_cmac_aes256_digest
-struct cmac128_ctx
+struct cmac128_key
{
- /* Key */
union nettle_block16 K1;
union nettle_block16 K2;
+};
+
+struct cmac128_ctx
+{
+ struct cmac128_key key;
/* MAC state */
union nettle_block16 X;
/* Block buffer */
- union nettle_block16 block;
size_t index;
+ union nettle_block16 block;
};
void
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Curve point decompression
Wim Lewis writes: > Point compression is easy enough, but point decompression requires > some curve math, potentially dependent on the specific curve, and some > of it is redundant with what's already done in ecc_point_set(). I think what's needed is basically a mod p square root. See RFC 6090 for one way to do it. (Btw, it might make sense to adopt the name "compact representation" from that document; the name "point compression" was probably invented to make the good old math sound more technical and impressive in patent filings). > So I > was thinking about moving this functionality into Hogweed as a > function along the lines of ecc_point_set_compressed(), which would > take, instead of a y-coordinate, an int containing the sign/parity of > the y-coordinate. For the details, it's good to have a specific reference to follow. There'a also been a feature request to convert points to and from ANSI x9.62, possibly related? Maybe converting to and from octest strings according to some specification is more useful as an advertised interface, than x coordinate + sign (not ruling out having both). > So my question for the list and for the maintainers is, is this a > reasonable API to add to Hogweed? Is there interest in including it in > Hogweed if I were to take the time to turn it into a tidy patch? It could make sense. Do you have any concrete use cases? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Add check for ECC at point 0
Simo Sorce writes:
> Attached find patch that adds points checks to the ECDH test case.
> Let me know if that's ok or if you prefer a whole new test.
I think it's ok to have it in the same file.
> -static void
> -set_point (struct ecc_point *p,
> -const char *x, const char *y)
> +static int
> +ret_set_point (struct ecc_point *p,
> + const char *x, const char *y)
> {
I think it's nicer to just change set_point to return int, and wrap
all existing calls in ASSERT, e.g,
- set_point (, ax, ay);
+ ASSERT (set_point (, ax, ay));
in test_dh. Or name functions as int set_point(...), void
set_point_or_die (...), but I think ASSERT is still clearer, in this
case.
> + test_public_key ("(0,0) with secp-192r1", &_nettle_secp_192r1, "0", "0",
> 0);
> + test_public_key (
> +"(P,0) with secp-192r1", &_nettle_secp_192r1,
> +"6277101735386680763835789423207666416083908700390324961279",
> + "0", 0);
Any particular reason the tests are all for secp_192r1 ?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 3/3] GOST curves generate larger overflows in mod arithmetics
Dmitry Eremin-Solenikov writes: > This patch makes things work for me. Is it only ecc_mod_submul_1 that you need to change? It's used via the ecc_modp_submul_1 macro. > Does it stand a chance to be applied? To accept the patch, I'd like to understand the mathematics and document what's required of the modulo to make it correct. And I'd also like to know if there's any measurable slowdown in examples/hogweed-benchmark or ecc-benchmark for the other curves. > For now I'm running ecc-mul-a-test and ecc-mul-g-test in a loop without any > errors. To make running in a loop useful, you need to add random seeding, see ecc-mod-test.c for an example to how to do it, enabled by the NETTLE_TEST_SEED environment variable. Used like while NETTLE_TEST_SEED=0 ./testsuite/ecc-mod-test ; do : ; done Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Release?
Nikos Mavrogiannopoulos writes: > I know of one or two applications that moved to nettle once the des > functionality was removed from libcrypt. Not sure if that's a good > reason to keep it, they are deprecated, but removing it may make it > slower to move to that version. But I'm not considering deleting des support (the things declared in des.h), only the libdes/openssl compatibility glue in des-compat.h. Ah, and there's also md5-compat.*, for api-compatibility with the RFC1321 reference implementation. This seems to be used by a few debian packages (radcli, chiark-utils, viking), see https://codesearch.debian.net/search?q=md5-compat.h, so I think we should keep it around; it's very simple and testing is better than for des-compat.h. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Release? (was: Re: curve448 branch)
Dmitry Eremin-Solenikov writes: > Is there anything that we can do to help with 3.5? I've just updated the NEWS file, please review. Since it's an ABI break, maybe a few more things could be deleted. * Can we delete _rsa_blind/_rsa_unblind (currently demoted from rsa.h to rsa-internal.h, and with internal symbol names). * dsa-compat.h (compatibility with Nettle older than 3.0)? * des-compat.h (compatibility with old libdes/openssl)? Also mentioned as a candidate for deletion when Nettle-3.0 was released. > I'm still playing around HMAC/digest refactoring, but I'm not happy with the > way code looks in my tree. I've committed changes to move buffers last in the hash context structs. That should make it a bit easier, but probably still not so pretty. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 3/3] GOST curves generate larger overflows in mod arithmetics
Dmitry Eremin-Solenikov writes: >> If p is close to B^size / 2, then I think a reduction like > > Yes, it is. > > As an overflow happens in low level code, do you suggest > duplicating ecc-dup-jj/ecc-add-jja/ecc-add-jjj for GOST curves? I'd prefer not to duplicate the point functions. Could consider doing these operations (or part of them) using indirection via some new function pointer in struct ecc_modulo. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 3/3] GOST curves generate larger overflows in mod arithmetics
Dmitry Eremin-Solenikov writes: >> Is it the condition b < B^size / p that is not valid for the GOST >> curves? What are the problematic values of b and p? > > I did not try debugging maths part of this issue. > Basically you can apply first two patches and then observe asserts failing > when running ecc-benchmark example. Problematic module looks like > 8...something. Bmodp then looks like 7fff.something. > > Any help at this point is appreciated. If p is close to B^size / 2, then I think a reduction like r <-- r - 2 * hi * p will get you close. I.e., hi -= mpn_submul_1(..., 2*hi) should almost cancel the most significant limb. After this, the common case is hi == 0, with possible error case being hi == -1 if p starts with 8000..., or hi == +1 if p starts with 7... It might be useful to precompute |2p - B^size|. For the larger reductions, does p have form suitable for redc, ending with ...1 of ...f? Current non-redc reduction code probably won't support p close to B^size / 2. >> To keep the ecc code side-channel silent, there must be no conditional >> jumps depending on hi (except for asserts, since they always branch the >> same way in a non-crashing program). The adjustmenst can only do >> unconditional calls to functions like mpn_add_mul_1 and cnd_add_1. > > Yes, thus I've tried adding a loop which should nearly always terminate with > just single compare after cnd_add_1. Unfortunately, "nearly always" isn't enough; it means that some inputs will result in a value of hi making the code branch differently, and that information then leaks through cache and/or timing. If it's likely to be exploitable, I can't say, but current ecc code is written to avoid that risk. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH 3/3] GOST curves generate larger overflows in mod arithmetics
Dmitry Eremin-Solenikov writes:
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> ecc-mod-arith.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/ecc-mod-arith.c b/ecc-mod-arith.c
> index f2e47f6747c1..571680a98dc3 100644
> --- a/ecc-mod-arith.c
> +++ b/ecc-mod-arith.c
> @@ -73,10 +73,12 @@ ecc_mod_mul_1 (const struct ecc_modulo *m, mp_limb_t *rp,
>assert (b <= 0x);
>hi = mpn_mul_1 (rp, ap, m->size, b);
>hi = mpn_addmul_1 (rp, m->B, m->size, hi);
> - assert (hi <= 1);
> - hi = cnd_add_n (hi, rp, m->B, m->size);
> - /* Sufficient if b < B^size / p */
> - assert (hi == 0);
> + do {
> +if (hi > 1) /* This is necessary for some of GOST curves */
> + hi = mpn_addmul_1 (rp, m->B, m->size, hi);
> +else
> + hi = cnd_add_n (hi, rp, m->B, m->size);
> + } while (hi != 0);
> }
Is it the condition b < B^size / p that is not valid for the GOST
curves? What are the problematic values of b and p?
To keep the ecc code side-channel silent, there must be no conditional
jumps depending on hi (except for asserts, since they always branch the
same way in a non-crashing program). The adjustmenst can only do
unconditional calls to functions like mpn_add_mul_1 and cnd_add_1.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: curve448 branch
Dmitry Eremin-Solenikov writes: > Niels, Daiki, do you have plans to update/merge curve448 branch? > I'd benefit from generalized Edwards curves support, which is part of > that branch. My plan was to merge it after the 3.5 release, in order to (i) to be able to do it without another abi breakage (in 3.4.x, the ecc curve symbols are exposed directly, and then changing the size of those structs breaks linking in some cases, due to copy relocations), and (ii) not delay 3.5 further. And now 3.5 is severely delayed compared to what I had hoped for. Not sure if re-plan is needed, or if I ought to focus on getting 3.5 out asap. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Add check for ECC at point 0
Simo Sorce writes: > While reviewing FIPS requirements for public key checks in Ephemeral > Diffie-Hellman key exchanges it came out that FIPS requires checks that > the public key point is not the (0, 0) coordinate and nettle is not > doing it (only checks that neither point is negative. ecc_point_set also checks that the point is on the curve, i.e., satisfies the curve equation. That should rule out (0, 0), except if we have some curve with constant term b == 0, which I don't think makes sense. Not sure how FIPS requirements are formulated, but maybe it would be better to add a test case to check that ecc_point_set rejects (0,0) ? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: SIV-CMAC
Nikos Mavrogiannopoulos writes: > Thanks. If you added the zero-nonce method, maybe it would be better > to add test vectors for it as well. I'm copying from my last patch > with it: I was about to add the miscreant.js examples (and with nettle's output, which is different), to illustrate interop issue. Unfortunately, the RFC 5297 testvectors appear useless if one wants to test the RFC 5116 mode of operation. And on second thought, maybe it makes more sense to change nettle to be interoperable with miscreant here? I think that's how you did it originally, and I found it confusing. RFC 5297 (SIV mode) says that for use according to RFC5116 (AEAD interface), N_MIN = 1. Another option, which you've also tried, is to to require non-empty nonce, i.e., add back the assert (nlength > 0), and define SIV_MIN_NONCE_SIZE as one, not zero. That's perhaps the most conservative approach: support for empty nonce, however that should behave, can be added later. Opinions? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: SIV-CMAC
Nikos Mavrogiannopoulos writes: > https://gitlab.com/nmav/nettle/merge_requests/4/ I've integrated this onto a branch siv-mode, with some changes (renamed functions to all have the siv_cmac prefix, document that empty nonce may have interop issues and should be considered experimental (but still allow it), and dropped some macros and unrelated changes (which would belong on a different branch). Please have a look, and say if I've messed up something. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Intel CET protection
Simo Sorce writes: > Ok attached find new patches, > they address all concerns except for adding the CET_SECTION macro > automagically to all asm files. Ah, one more thing: > +define(, > + +<.pushsection .note.gnu.property,"a" How portable is .pushsection? If we ensure that notes are last, plain .section should be enough, I think. > --- a/x86_64/sha3-permute.asm > +++ b/x86_64/sha3-permute.asm > @@ -107,6 +107,7 @@ define(, < > > C sha3_permute(struct sha3_state *ctx) > .text > +GNU_CET_SECTION() > ALIGN(16) > PROLOGUE(nettle_sha3_permute) > W64_ENTRY(1, 16) This placement between .text and the prologue depends on .pushsection / .popsection. I think it should be moved last, just like in the other files, either explicitly or by means of a divert in some of the included m4 files. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Intel CET protection
Simo Sorce writes: > they address all concerns except for adding the CET_SECTION macro > automagically to all asm files. Thanks. I commented on that issue in my other mail. > I also added a patch to deal with the missing epilogues. Applied now. BTW are there any git experts here? I often apply complete patches by running cd hack/nettle/ && git am directly on the text/x-patch attachment (the | command on the attachment in Gnus' *Article* buffer). But all of git am, git apply, git am -3, git apply -3 failed on this Patch #3, most likely because line numbers depended on the earlier patches in the series, which I didn't want to apply right away. Old-fashioned patch -p1 could apply the patch, with "fuzz 2". So are there any other options to make the git patching tools a bit more tolerant or fuzzy? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Intel CET protection
Simo Sorce writes: > I understand this is not a high bar, and I will fold the segment note > in if you think that is what we should do, but I wanted to make you > aware of why I did not do the same as what we do with the stack note. I think we should aim to make all files "cet-compliant" if we do it att all. After all, the common case is to have a libnettle.so, and then any single object file missing the annotation will make the linker disable the feature, if I've understood it correctly. I agree it should be disabled by default until we're more confident in test coverage. BTW, do you know how that works with late loading using dlopen? One could have a process running in CET-mode, which dynamically loads an so-file with code lacking endbr instructions and corresponding annotation. If we think about it as an arch-specific thing, which I guess we should, then maybe the m4 divert should be in x86_64/machine.m4 and x86/machine.m4, not asm.m4. > That is funny, I actually used CET_ENDBR to make it easier to find for > others grepping as binutils also uses a _CET_ENDBR macro, it sounded > more consistent I agree your name is better for readability, even if less amusing. >> I'd like to understand what's missing. Maybe we can fix it more >> explicitly? > > I do not think we can easily fix it manually, it is mostly other > section notes that the gcc compiler adds when it fortifies C code. But > those notes do not really apply to handcrafted assembly. [...] > So this flag > is basically just saying to the compiler that it should add whatever is > appropriate (which may change depending on compiler flags) because our > code is good as is. Since the command line flag is passed with -Wa, it tells the *assembler* to add notes. Which ones? Is it based only on the command line, say, $(CFLAGS) contains -fharden-foo makes the assembler produces a "foo" note. Or is it based on what's actually in the assembly input file? Is there a risk that it automatically generates a note promising something about the assembly code which we don't actually fulfill? Is there any documentation? I see that it is mentioned in the binutils-2.31 release announcement, but I've not found it mentioned in the Gas manual. > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > (I do no have a better link) Looks like reasonable doc. (Closest on wikpedia seems to be https://en.wikipedia.org/wiki/Control-flow_integrity). > See above explanation and let me know if that changes your opinion, > otherwise I will do this. > >> > +ALIGN(8) >> > +.long 1f - 0f >> > +.long 4f - 1f >> > +.long 5 >> > +0: >> > +.string "GNU" >> > +1: >> > +ALIGN(8) >> > +.long 0xc002 >> > +.long 3f - 2f >> > +2: >> > +.long 0x03 >> > +3: >> > +ALIGN(8) >> > +4: >> >> Are there no symbolic names for this note? Since we require assembler to >> suport endbr instructions, can we require that it know about these notes >> as well? What does it look like in gcc output? > > There are symbolic names to compose the 0x03 value and for the > 0xc002 values, the rest are just label arithmetic. > > I will change in next submission. I see, I was hoping for something more similar to .section .note.GNU-stack,"",TYPE_PROGBITS I'm still curious as to what it looks like in gcc output. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Intel CET protection
Simo Sorce writes: > the attached patches have been used to successfully enable and test > Intel CET support in an Intel emulator on SDV hardware. Thanks. > GCC already has all the needed support to create CET hardened code, > however the hand-coded assembly needs to be changed to conform. > Without these changes all the binaries that load nettle will otherwise > have CET disabled, as it is an all-or-nothing at the binary level and > missing ENDBRANCH instruction cause the program to terminate on > indirect jump/call instructions. For the .note.gnu.property thing (which is per object file, right?), I think it's better to do it in the same place as ASM_MARK_NOEXEC_STACK. That's substituted in config.m4.in, and added at the end of each asm file using m4 divert. The endbr instructions in the prologue are in the right place, as far as I can tell. And I'd be very tempted to rename the macro CET_ENDBR to COME_FROM, see https://en.wikipedia.org/wiki/COMEFROM ;-) > The second patch is used to make the system happy when hardening flags > are enabled in gcc, as it generates the appropriate section information > that tells the linker all is good. I'd like to understand what's missing. Maybe we can fix it more explicitly? > Finally while looking at the assembly I noticed that some functions > have a PROLOGUE() defined but not an EPILOGUE() macro defined in their > .asm files. It is unclear to me if this is an error or intentional so > didn't touch those, it doesn't affect functionality for this patch > anyway. I think it's an error. Except in the files in arm/fat with lines like dnl PROLOGUE(_nettle_chacha_core) picked up by configure I find three offending files, using $ diff <(git grep -c '^ *EPILOGUE') <(git grep -c '^ *PROLOGUE') 49c49 < x86_64/poly1305-internal.asm:2 --- > x86_64/poly1305-internal.asm:3 51a52,53 > x86_64/serpent-decrypt.asm:1 > x86_64/serpent-encrypt.asm:1 have you seen any others? Some minor comments below. > From de1b9bfeb4f8ad9a6bf8608c4b8c727dba315982 Mon Sep 17 00:00:00 2001 > From: Simo Sorce > Date: Tue, 23 Apr 2019 18:03:35 -0400 > Subject: [PATCH 1/2] Add Intel CET protection support > > In upcoming processors Intel will make available Control-Flow > Enforcement Technology, which is comprised of two hardware > countermeasures against ROP based attacks. Please spell out ROP. It would be good with a link to further information in some reasonable place in the code. > The first is called Shadow Stack and checks that return from function > calls are not tampered with by keeping a shadow stack that cannot be > modified by aplications. This measure requires no code changes (except > for code that intentionally modifes the return pointer on the stack). Fix spelling of "aplication", "modifes" > The second is called Indirect Branch Tracking and is used to insure only > targets of indirect jumps are actually jumped to. This requires > modification of code to insert a special instruction that identifies a > valid indirect jump target. When enforcement is turned on, if an indirect > jump does not end on this special instruction the cpu raises an exception. > These instructions are noops on older CPU models so it is safe to use > them in all x86(_64) code. > > To enable these protections gcc also inroduces a new GNU property note and "inroduces" > +dnl GNU properties section to enable CET protections > +define(, > + +<.pushsection .note.gnu.property,"a" As I said, prefer to dot his globally with an m4 divert in config.m4.in. > +ALIGN(8) > +.long 1f - 0f > +.long 4f - 1f > +.long 5 > +0: > +.string "GNU" > +1: > +ALIGN(8) > +.long 0xc002 > +.long 3f - 2f > +2: > +.long 0x03 > +3: > +ALIGN(8) > +4: Are there no symbolic names for this note? Since we require assembler to suport endbr instructions, can we require that it know about these notes as well? What does it look like in gcc output? > diff --git a/x86_64/aes-decrypt-internal.asm b/x86_64/aes-decrypt-internal.asm > index 43f2f394..5db39868 100644 > --- a/x86_64/aes-decrypt-internal.asm > +++ b/x86_64/aes-decrypt-internal.asm > @@ -62,7 +62,7 @@ C work. > define(,<%rbp>) > > .file "aes-decrypt-internal.asm" > - > + > C _aes_decrypt(unsigned rounds, const uint32_t *keys, > C const struct aes_table *T, > C size_t length, uint8_t *dst, > @@ -70,6 +70,7 @@ define(,<%rbp>) > .text > ALIGN(16) > PROLOGUE(_nettle_aes_decrypt) > + Please trim unrelated whitespace changes from the patch (I known it's not 100% consistent, but if we ever want to do something like M-x whitespace-cleanup on all files, that should be in a separate co
Re: SIV-CMAC
Nikos Mavrogiannopoulos writes:
>> In this function, you treat empty associated data or nonce as those
>> elements missing in the input vector to S2V. E.g., if both adata and
>> nonce are empty, the input vector is { plaintext }, one single
>> element.
>> But it could also be { "", "", plaintext }, with three elements, the
>> first two being empty strings.
>
> While the low level function could handle it, it is not exposed to be
> called directly (mainly intentionally as this cipher introduces a very
> new paradigm which I do not quite see much of practical uses).
>
> This patch only adds the higher level AEAD API only, so this case
> cannot happen as we don't have the notion of empty string
> in nettle. We can introduce it of course, though we may be opening a
> can of worms as not only empty strings are undefined in terms of AEAD
> API [0], but what would these mean in the other implementations?
>
> [0]. https://tools.ietf.org/html/rfc5116#section-2
By empty string I simply meant a string of length 0. As I read RFC 5116,
it requires that the key is between 1 and 255 octets (inclusive), but
all of nonce, plaintext and associated data may consist of zero octets.
>> To me, this sounds like a likely source of interop problems. Since
>> RFC
>> 5297 is general and allows the application to decide on the number of
>> elements and meaning of the input vector, it doesn't give much
>> guidance on this, as far as I see. The crucial case is when an
>> application specifies that SIV is used with associated data and/or a
>> nonce, but allows an empty string for either of those.
>
> I agree on that. That's one of the reasons I stuck on the higher level
> AEAD API (expressed by the message APIs in nettle). I added two
> sentences in the documentation about it.
The thing is, the AEAD api should allow inputs to be zero-length
strings. Then the question is how to treat zero-length inputs in
_siv_s2v, and I don't find RFC 5297 crystal clear on this point.
To me, it would make most sense for the AEAD construction to always use
the S2V function in the spec with S1 = associated data (possibly zero
length), S2 = nonce (possibly zero length), S3 = plaintext (possibly
zero length). But we need to do what's needed to make it easy to
interoperate with applicatinos and protocols using SIV; if everyone else
does this differently, we should probably follow.
If we do it this way, then the nonce-less "key wrapping" usecase
mentioned in RFC5297, with the example in A1, is *not* a special case of
the AEAD construction, since this mode uses S1 = associated data, S2 =
plaintext.
If we need to support several modes, maybe we should have a context
struct that lets us do S2V incrementally, one element at a time,
siv_add_adata(struct siv_ctx *ctx, size_t length, const uint8_t *data);
called zero or more times, followed by
siv_encrypt(struct siv_ctx *ctx, size_t clength, uint8_t *dst, const uint8_t
*src);
which does the CMAC of the plaintext (the final S2V element), extracts
V, and does the encryption. (S2V is defined also for n == 0, but that's
not very useful and we don't need to support it).
But I think we should start with the AEAD-style api with both adata and
nonce mandatory (but possibly empty), before worrying too much about
generalizations.
> Done. It needed some reorganization, and cmac128_syn is still needed in
> an ugly simulation of the CMAC structure setup to use the macros. I
> have kept the union
Maybe it would be easier without using the CMAC macros. They're intended
for convenience, so there's little point in using them where it doesn't
bring any convenience.
> The attached version should address the comments so far and also
> changes cmac128_set_key to use nettle_block16 as well.
Thanks! I hope to read through the new patch during the weekend.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: SIV-CMAC
Nikos Mavrogiannopoulos writes:
> On Sun, 2019-04-14 at 09:33 +0200, Niels Möller wrote:
>> > +typedef int
>> > +nettle_decrypt_message(void *ctx,
>> > + size_t nlength, const uint8_t *nonce,
>> > + size_t alength, const uint8_t *adata,
>> > + size_t tlength,
>> > + size_t mlength, uint8_t *dst, const uint8_t
>> > *src);
>> > +
>>
>> In this patch, these types used in tests only. But I imagine you'd
>> like something in nettle-meta to represent a message-oriented aead?
>
> I have never used the nettle-meta interface for ciphers, so I'm not
> sure about whether that's needed or not. CCM for example is not
> represented there. Would it make sense to separate the meta interface
> from the addition of the cipher, or should I avoid adding the type
> completely?
Put these typedefs in testutils.h for now, if you find them useful for
the tests.
>> Some detail on the nonce-reuse would be helpful. As I understood RFC
>> 5297, the nonce used in SIV is only to make the ciphertexts of
>> otherwise identical messages look different to the attacker.
> My understanding of this RFC is that a primary goal as in 1.3.2, is to
> be resistant to nonce misuse (e.g., if you re-use the nonce). I can add
> more information but I am not sure I understand which direction of
> detail you mean. What are you missing or think is unclear in the text?
Something brief on what the consequences are if one accidentally or
deliberately uses the same nonce twice. You could even quote the rtc, if
it expresses it well and concisely.
>
>> > --- /dev/null
>> > +++ b/siv-aes128-cmac.c
>> > @@ -0,0 +1,79 @@
>> [...]
>> > +void
>> > +siv_aes128_cmac_encrypt_message(struct siv_aes128_cmac_ctx *ctx,
>> > + size_t nlength, const uint8_t *nonce,
>> > + size_t alength, const uint8_t *adata,
>> > + size_t tlength,
>> > + size_t slength, uint8_t *dst, const
>> > uint8_t *src)
>> > +{
>> > + assert(tlength == SIV_DIGEST_SIZE);
>>
>> The tlength argument doesn't look that useful, do we need it?.
>
> If we remove the tlength then it would not implement the
> nettle_encrypt_message_func(). My goal in keeping tlength was to have a
> consistent interface across the message oriented ciphers.
I'd prefer to not have the tlength argument. If we do a
nettle-meta-style interface for messge-oriented aead, we may use a fix
tlength, so that, e.g., CCM with full tag length (16 bytes) nd truncated
tag (say, 4 bytes) would be considered distinct aead algorithms.
>> Also, I
>> think we agreed that the message length argument should be the size
>> of
>> the *destination* area, i.e., ciphertext size for encrypt_message
>> (see
>> ccm_*_encrypt_message):
>
> I can name it clength, but there is the implicit assumption that
> clength = slength right? Otherwise if a larger buffer is provided for
> destination, I do not see how it figure the source size.
clength == tlength + slength. This is what the docs for the
corresponding ccm functions say (which do have tlength argument, since
ccm supports truncated tag) say:
The CCM message fuctions provides a simple interface that will perform
authentication and message encryption in a single function call. The
length of the cleartext is given by MLENGTH and the length of the
ciphertext is given by CLENGTH, always exactly TLENGTH bytes longer than
the corresponding plaintext. The length argument passed to a function
is always the size for the result, CLENGTH for the encryption functions,
and MLENGTH for the decryption functions.
>> > --- /dev/null
>> > +++ b/siv-cmac.c
>> > @@ -0,0 +1,194 @@
>> > +/* This is a common structure for AES-128 and AES-256 thus
>> > + * for the cipher part we simply pad to the maximum structure
>> > + * size plus 16 bytes to account for any alignment difference in
>> > + * the original structures */
>> > +struct cmac128_syn {
>> > + struct cmac128_ctx ctx;
>> > + struct {
>> > +uint8_t pad[NETTLE_MAX_CIPHER16_CONTEXT_SIZE+16];
>> > + } cipher;
>> > +};
>>
>> I don't think this guarantees any alignment. You would either need
>> soemthing like
>>
>> struct cipher_storage {
>> union {
>> uint64_t u64;
>> char c[NETTLE_MAX_CIPHER16_CONTEXT_SIZE];
>> } storage;
>> };
>> ...
>> CMAC128_CTX(cipher_storage) ctx;
>
> The goal here was not to make c aligned, but to have enough
Re: [PATCH][v2] fat-arm.c: prefer getauxval() over /proc/cpuinfo parsing
"Yuriy M. Kaminskiy" writes:
> On 14.03.2019 08:41, Niels Möller wrote:
>> "Yuriy M. Kaminskiy" writes:
>>
>>> When compiled for armv6+ and getauxval() is present (glibc 2.16+),
>>> avoid slow and unreliable /proc/cpuinfo parsing.
>>>
>>> E.g. /proc/cpuinfo contains junk with qemu-user and can be unavailable
>>> in some chroot environment.
>>
>> Do you know what's the preferred way to do this on android? Do we still
>> need /proc/cpuinfo, or are there any library facilities?
>
> Google suggests https://developer.android.com/ndk/guides/cpu-features
> I have no experience with it.
That page says that getauxval is available on later versions ("API level
18" and later, whatever that means). So should hopefully work, with the
same configure check.
Not sure if there's any easy way to test on android, without downloading
either the ndk (with whatever license agreements required) or just the
cross-compiler binaries. Is http://android-rebuilds.beuc.net/ the way to
go? I also tried native compile under termux a while ago, but configure
failed because there was no /bin/sh.
> There are (const char *)getauxval(AT_PLATFORM); it is expected to be
> "v[45678][lb]";
> probably, I should use it.
>
> Things that should be checked: arm (32bit) userland with aarch64/arm64 kernel.
Any progress on this? I'd really like to have the arch version check
also done via getauxval, if that's possible.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: SIV-CMAC
ely source of interop problems. Since RFC
5297 is general and allows the application to decide on the number of
elements and meaning of the input vector, it doesn't give much
guidance on this, as far as I see. The crucial case is when an
application specifies that SIV is used with associated data and/or a
nonce, but allows an empty string for either of those.
Also encoding empty adata, nonce "foo" in the same way as adata "foo",
empty nonce, seems like a subtlety contrary to the spirit of 1.3.3.
> +void
> +siv_cmac_set_key(struct siv_cmac_ctx *ctx, void *cipher,
> + const struct nettle_cipher *nc,
> + const uint8_t *key)
> +{
> + unsigned skey_size = nc->key_size;
> +
> + assert(skey_size <= SIV_MAX_KEY_SIZE/2);
> + memcpy(ctx->s2vk, key, skey_size);
I think this function should do the underlying key setup also for the
cipher instance used for s2v, not just store the key for later. So then
the function would be
void
siv_cmac_set_key(void *cmac_cipher, void *ctr_cipher,
const struct nettle_cipher *nc,
const uint8_t *key)
with no struct siv_cmac_ctx.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] nettle-pbkdf2.c: change the initialization for salt
Alon Bar-Lev writes:
> Isn't this a bug in libc/strdup and not in nettle? This implementation
> is the same as what expected from strdup.
I agree. Please file a bug report for the C library you're using. strdup
is a standard posix function (if not part of the C language standard),
and widely used, see
https://codesearch.debian.net/search?q=strdup=1
> As a workaround I would have added CPPFLAGS="-Dstrdup(x) " instead
> of introducing workarounds for libc bugs,
-D'strdup(x)=strcpy(malloc(strlen(x)+1, x))'
might work (since strcpy returns the pointer to the destination string).
> However, looking at the code, I believe the allocation of memory is
> not required... it can be:
The if (hex_salt) {...} block overwrites the salt storage, for in-place
hex decoding. I don't quite like overwriting the strings passed in via
argv, even if it might be possible. So when I wrote this tool, always
allocating a writable copy, and calling free unconditionally, seemed
nice and easy,
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: nettle-pbkdf2 Segmentation fault
"Yu, Mingli" writes:
> Program received signal SIGSEGV, Segmentation fault.
> nettle_sha256_update (ctx=0x7fffe5c0, length=,
> data=0x9260 )
> at ../nettle-3.4.1/sha256.c:99
> 99../nettle-3.4.1/sha256.c: No such file or directory.
> (gdb) bt
> #0 nettle_sha256_update (ctx=0x7fffe5c0, length=,
> data=0x9260 )
> at ../nettle-3.4.1/sha256.c:99
> #1 0x77fa9bb6 in nettle_pbkdf2
> (mac_ctx=mac_ctx@entry=0x7fffe4e0,
> update=0x77fa7cb0 ,
> digest=0x77fa7cc0 ,
> digest_size=digest_size@entry=32, iterations=iterations@entry=1,
> salt_length=salt_length@entry=4,
> salt=0x9260 ,
> length=16, dst=0xa290 "") at ../nettle-3.4.1/pbkdf2.c:78
> #2 0x77fa9dd3 in nettle_pbkdf2_hmac_sha256 (
> key_length=, key=, iterations=1,
> salt_length=4,
> salt=0x9260 ,
> length=16, dst=0xa290 "")
> at ../nettle-3.4.1/pbkdf2-hmac-sha256.c:51
> #3 0x544c in main (argc=, argv=)
> at ../../nettle-3.4.1/tools/nettle-pbkdf2.c:167
Not sure if everything here can be trusted, but the
salt=0x9260 ,
in the backtrace indicates some problem with the salt passed down fron
the nettle-pbkdf2 tool to the nettle library functions.
It's allocated as
salt = strdup (argv[0]);
at line 146 in tools/nettle-pbkdf2.c (after an argv += optind). I note
that there's no check of the return value, but if strdup fails it should
return NULL, which would be a different invalid address.
You may want to examine the values of those variables in the debugger or
with debug printouts. E.g, try this patch.
--- a/tools/nettle-pbkdf2.c
+++ b/tools/nettle-pbkdf2.c
@@ -144,6 +144,11 @@ main (int argc, char **argv)
}
salt = strdup (argv[0]);
+ if (!salt)
+die ("strdup failed: Virtual memory exhausted.\n");
+ fprintf(stderr, "argv[0]: '%s'\n", argv[0]);
+ fprintf(stderr, "copy (salt): '%s'\n", salt);
+
salt_length = strlen(argv[0]);
if (hex_salt)
>>>> What kind of machine, operating system, and compiler are you using?
>>>> Since the testsuite passes on the test systems (including x86_64 and
>>>
>>> I work on x86_64 and use gcc for compiler.
And operating system, please?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: nettle-pbkdf2 Segmentation fault
"Yu, Mingli" writes: > It's 3.4.1 and I did use it as below: > # echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt That's the latest version. >> Can you get a backtrace? (start "gdb nettle-pbkdf2", at the gdb prompt > > I don't know how to use nettle-pbkdf2 actually and it didn't return > when I run as below: > # nettle-pbkdf2 -i 1 -l 16 salt Sorry, it wants to read the input password on stdin. Try echo foo > /tmp/foo, and then start it in gdb as run nettle-pbkdf2 -i 1 -l 16 salt < /tmp/foo What kind of machine, operating system, and compiler are you using? Since the testsuite passes on the test systems (including x86_64 and cross-compile setup for arm and mips), I imagine it's something somewhat unusual. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: nettle-pbkdf2 Segmentation fault
"Yu, Mingli" writes: > # echo -n passwd| nettle-pbkdf2 -i 1 -l 16 > [65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip > 7f3332256998 sp 7fff60d44410 error 4 in > libnettle.so.6.5[7f3332244000+1d00] > [65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d 41 > 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9 68 > ff f > Segmentation fault I can't reproduce this crash. Gives me a usage message, and if I add a salt argument, I get a hex digest out, as expected. Which version and platform are you using? Can you get a backtrace? (start "gdb nettle-pbkdf2", at the gdb prompt type "run -i 1 -l 16", if it crashes, type "bt" for backtrace). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [WIP] aes arm asm from libgcrypt
"Yuriy M. Kaminskiy" writes: I've had another look, trying to understand how it differs. > Does not use pre-rotated tables (as in AES_SMALL), so reduces d-cache > footprint from 4.25K to 1K (enc)/1.25K (dec); > completely unrolled, so increases i-cache footprint > from 948b to 4416b (enc)/4032b (dec) Not sure unrolling is that beneficial; Nettle's implementation does two rounds at a time (since just like in your patch, src and destination registers alternate when doing a round), and that's so many instructions that lop iverhead should be pretty small. > As it completely replaces current implementation, I just attached new > files (will post final version as a patch). As you say, it doesn't use prerotated tables, but instead adds a , ror #x to the relevant eor instructions. Load and store of the cleartext and ciphertext bytes is different (and I have some difficulty following it). Masking to get table indices is the same as in nettle's arm/aes-encrypt-internal.asm, while nettle's v6 code uses the uxtb instruction, which saves one register (which the code doesn't take much advantage of, though). The code in your patch has more careful instruction scheduling, e.g., interleaving addition of roundkeys with the sbox table lookups. Nettle's code is written with only a single temporary register used for everything, which makes it impossible to interleave independent parts of the mangling. While your patch seems to alternate between three different temporaries. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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. Merged to master branch now. Thanks! /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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
> +
> +The @acronym{AES} @acronym{XTS} functions provide an API for using the
> +@acronym{XTS} mode with the @acronym{AES} block ciphers. The parameters
> +all have the same meaning as the general interface, except that the
> +@var{enc_ctx}, @var{dec_ctx}, @var{twk_ctx}, @var{encf} and @var{decf} are
> +replaced with an @acronym{AES} context structure called @var{ctx}, and a
> +appropriate set-key function must be called before using any of the
> encryption
> +or decryption functions in this interface.
> +
> +@deftp {Context struct} {struct xts_aes128_ctx}
> +Holds state corresponding to the AES-128 block cipher.
> +@end deftp
> +
> +@deftp {Context struct} {struct xts_aes256_ctx}
> +Holds state corresponding to the AES-256 block cipher.
> +@end deftp
These structs were renamed from _ctx to _key, right?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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 __builtin_bswap64 when provided by gcc or its look-alikes. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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 annoying to repeat duplicate code for a final complete
block, but no big deal. Alternative ways to do the final block of the
non-stealing case (including the case of exactly one block) are
for (; length >= 2 * XTS_BLOCK_SIZE || length == XTS_BLOCK_SIZE; ...)
{
...
}
if (length > 0)
{
... steal ...
}
or (since we require at least one block)
do {
...
length -= XTS_BLOCK_SIZE;
if (!length)
return;
} while (length >= 2*XTS_BLOCK_SIZE);
Do what you think makes it clearest.
For the tests, have you checked that there's coverage for the special
wraparound? I.e., that tests fail if the line
dst->b[0] ^= 0x87 & -carry;
is changed. Since there are a very small number of test vectors with
more than one block, we could be unlucky and have carry == 0 all the
time when xts_shift is called from the tests...
>> > +static void
>> > +check_length(size_t length, uint8_t *dst)
>> > +{
>> > + assert(length >= XTS_BLOCK_SIZE);
>> > + /* asserts may be compiled out, try to save the user by zeroing the dst
>> > in
>> > + * case the buffer contains sensitive data (like the clear text for
>> > inplace
>> > + * encryption) */
>> > + if (length < XTS_BLOCK_SIZE)
>> > +memxor(dst, dst, length);
>> > +}
Why memxor rather than memset?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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 system where something more complicated is >known to improve performance. 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 carry out ^ Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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 reads and writes. For xts_shift, there are three cases, and I think they could be handled like this: 1. Little-endian system: Use 64-bit reads and writes, no swaps needed. 2. Big-endian system, __builtin_bswap64 detected (HAVE_BUILTIN_BSWAP64): Use 64-bit reads and writes + __builtin_bswap64. 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 system where something more complicated is known to improve performance. In case (1) or (2), use 64-bit operations exclusively, also for the carry logic. And then the macros and #ifdefs should be arranged to make it not too ugly. E.g., cases (1) and (2) could perhaps be combined, with a BSWAP64_IF_BE macro or the like. Or a macro like LE_READ_ALIGNED_UINT64 (with an uint64_t * argument) Only current use of __builtin_bswap64 is in ctr.c, the ctr_fill16 function. An older example is in salsa20-core-internal.c, with a LE_SWAP32 macro. That one could take advantage of __builtin_bswap32, if available. I don't know if the compiler can recognize the current expression as a byte swap. And it probably is more important to optimize xts_shift if/when one also arranges the code to produces multiple blocks of T_k values at a time (say, 32 blocks, 512 bytes of stack-allocated temporary storage), without reading the intermediate values back from memory to registers. That has been a significant optimization for both ctr mode and cbc decrypt. I haven't reviewed the new version of the patch yet, I hope to get to that in a day or two. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
> + for (;length >= XTS_BLOCK_SIZE;
> + length -= XTS_BLOCK_SIZE, src += XTS_BLOCK_SIZE, dst +=
> XTS_BLOCK_SIZE)
> +{
> + memcpy(P.b, src, XTS_BLOCK_SIZE);
> + memxor(P.b, T.b, XTS_BLOCK_SIZE); /* P -> PP */
This is what memxor3 is for. (If it's more efficient in this case is not
entirely
obvious, though).
> +/* XTS Mode with AES-128 */
> +struct xts_aes128_ctx {
> +struct aes128_ctx cipher;
> +struct aes128_ctx tweak_cipher;
> +};
Could consider renaming it to xts_aes128_key, somewhat analogous to
struct eax_key and struct gcm_key. This represents message-independent
data, and then the name xts_aes128_ctx could be used in case we add an
interface with a buffer and incremental encryption and decryption. Not
clear to me if that's likely or not to ever be useful, though.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [WIP] aes arm asm from libgcrypt
"Yuriy M. Kaminskiy" writes:
> On raspberry pi 3b+ (cortex-a53 @ 1.4GHz):
> Before:
> aes128 | nanosecs/byte mebibytes/sec cycles/byte
> ECB enc | 39.58 ns/B 24.10 MiB/s - c/B
> ECB dec | 39.57 ns/B 24.10 MiB/s - c/B
> After:
> ECB enc | 15.24 ns/B 62.57 MiB/s - c/B
> ECB dec | 15.68 ns/B 60.80 MiB/s - c/B
>
> Passes nettle regression test (only little-endian though)
Cool!
> Does not use pre-rotated tables (as in AES_SMALL), so reduces d-cache
> footprint from 4.25K to 1K (enc)/1.25K (dec);
We could ficgure out a way to exclude unneeded tables in builds that
unconditionally uses this code.
I think I tried this years ago, and found it slower, recorded in this
comment:
C It's tempting to use eor with rotation, but that's slower.
But things may have changed, or you're doing it in a different way than
I tried. Have you benchmarked with small and large tables?
> completely unrolled, so increases i-cache footprint
> from 948b to 4416b (enc)/4032b (dec)
Do you have any numbers for the performance gain from unrolling?
With complete unrolling, it may be good with separate entry points (and
possibly separate files) for aes128, aes192, aes256. I've been
considering doing that for the x86_64/aesni (and then the old-style
aes_encrypt needs to be changed to not use the _aes_encrypt function
with a rounds argument; I have a branch doing that lying around
somewhere).
> P.S. Yes, I tried convert macros to m4: complete failure (no named
> parameters, problems with more than 9 arguments, weird expansion rules);
> so I fallen back to good ol' gas. Sorry.
No named arguments may be a bit annoying. At least for the AES code, I
see no macros with more than 9 arguments.
> define(,)
> define(, KEYSCHEDULE_REVERSED,yes,<$1>,
> KEYSCHEDULE_REVERSED,no,<$2>)>)
What is this for?
> C helper macros
> .macro ldr_unaligned_le rout rsrc offs rtmp
> ldrb \rout, [\rsrc, #((\offs) + 0)]
> ldrb \rtmp, [\rsrc, #((\offs) + 1)]
> orr \rout, \rout, \rtmp, lsl #8
> ldrb \rtmp, [\rsrc, #((\offs) + 2)]
> orr \rout, \rout, \rtmp, lsl #16
> ldrb \rtmp, [\rsrc, #((\offs) + 3)]
> orr \rout, \rout, \rtmp, lsl #24
> .endm
A different way to read unaligned data is to read aligned words, and
rotate and shift on the fly. There's an example of this in
arm/v6/sha256-compress.asm, using ldm, sel and ror, + some setup code
and one extra register for keeping left-over bytes.
> PROLOGUE(_nettle_aes_decrypt)
> .cfi_startproc
> teq PARAM_LENGTH, #0
> bxeqlr
>
> push {r0,r3,%r4-%r11, %ip, %lr}
> .cfi_adjust_cfa_offset 48
> .cfi_rel_offset r0, 0 C PARAM_LENGTH
> .cfi_rel_offset r3, 4 C PARAM_ROUNDS
> .cfi_rel_offset r4, 8
> .cfi_rel_offset r5, 12
> .cfi_rel_offset r6, 16
> .cfi_rel_offset r7, 20
> .cfi_rel_offset r8, 24
> .cfi_rel_offset r9, 28
> .cfi_rel_offset r10, 32
> .cfi_rel_offset r11, 36
> .cfi_rel_offset ip, 40
> .cfi_rel_offset lr, 44
Are these .cfi_* pseudoops essential? I'm afraid I'm ignorant of the
fine details here; I just see from the gas manual that they appear to be
related to stack unwinding.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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-place operations */
> static void
> xts_shift(union nettle_block16 *dst,
> const union nettle_block16 *src)
> {
> uint8_t carry = src->b[15] >> 7;
> dst->u64[1] = (src->u64[1] << 1) | (src->u64[0] >> 63);
> dst->u64[0] = src->u64[0] << 1;
> dst->b[0] ^= 0x87 & -carry;
> }
This will then work only on little-endian systems?
I think it would be nice with a structure like
b0 = src->u64[0]; b1 = src->u64[1]; /* Load inputs */
... swap if big-endian ...
uint64_t carry = (b1 >> 63);
b1 = (b1 << 1) | (b0 >> 63)
b0 = (b0 << 1) ^ (0x87 & -carry);
... swap if big-endian ...
dst->u64[0] = b0; dst->u64[1] = b1; /* Store output */
I.e., no memory accesses smaller than 64-bits.
Possibly with load + swap and swap + store done with some
system-dependent macros.
But it's not essential for a first version of xts; copying block_mulx
and just replacing READ_UINT64 with LE_READ_UINT64 and similarly for
WRITE would be ok for now. There are more places with potential for
micro-optimizations related to endianness. While I think the
READ/WRITE_UINT macros are adequate in most places where unaligned
application data is read and written by C code.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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 block is > provided. This means inputs and outputs would not be symmetrical and I > felt it would make it somewhat hard to deal with as an API. > In general XTS is used for block storage and the input is always fully > available (and relatively small, either around 512 bytes, or 4k). I see. Can you mention this (and the fact that messages must be at least one full block) in the manual? Would it make sense to rename functions to xts_encrypt_message, xts_decrypt_message, to emphasize that they operate on complete messages? That would be analogous with the ccm message functions. >> So the second key, with E_k2, is only ever used to encrypt the IV? If >> you add a set_iv function, that could do this encryption and only store >> E_k2(IV). > > What would be the advantage ? With an api for complete messages only, my suggestion makes little sense. > Looks the same indeed, should I share it? Just copy it from cmac? > Something else? Would be nice to share it, but since it's so short, duplication is no big deal. Also re-reading the cmac version, block_mulx, I think it's unfortunate to use READ_UINT64 and WRITE_UINT64, since arguments are aligned. It would be preferable to load 64-bit values and use __builtin_bswap64 when needed and available (see ctr.c for a similar hack). But that's an independent improvement. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Implement XTS block cipher mode
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 signatures follows the same pattern used by other block-
> cipher modes like ctr, cfb, ccm, etc...
But it looks like one has to pass the complete message to one call?
Other modes support incremental encryption (with the requirement that
all calls but the last must be an integral number of blocks). I.e.,
calling sequence like
xts_aes128_set_key
xts_aes128_set_iv
xts_aes128_encrypt ... // 1 or more times
xts_aes128_set_iv // Start new message
xts_aes128_encrypt ... // 1 or more times
> +The @code{n} plaintext blocks are transformed into @code{n} ciphertext blocks
> +@code{C_1},@dots{} @code{C_n} as follows.
> +
> +For a plaintext length that is a perfect multiple of the XTS block size:
> +@example
> +T_1 = E_k2(IV) MUL a^0
> +C_1 = E_k1(P_1 XOR T_1) XOR T_1
> +
> +@dots{}
> +
> +T_n = E_k2(IV) MUL a^(n-1)
> +C_n = E_k1(P_n XOR T_n) XOR T_n
> +@end example
> +
> +For any other plaintext lengths:
> +@example
> +T_1 = E_k2(IV) MUL a^0
> +C_1 = E_k1(P_1 XOR T_1) XOR T_1
> +
> +@dots{}
> +
> +T_(n-2) = E_k2(IV) MUL a^(n-3)
> +C_(n-2) = E_k1(P_(n-2) XOR T_(n-2)) XOR T_(n-2)
> +
> +T_(n-1) = E_k2(IV) MUL a^(n-2)
> +CC_(n-1) = E_k1(P_(n-1) XOR T_(n-1)) XOR T_(n-1)
> +
> +T_n = E_k2(IV) MUL a^(n-1)
> +PP = [1..m]Pn | [m+1..128]CC_(n-1)
> +C_(n-1) = E_k1(PP XOR T_n) XOR T_n
> +
> +C_n = [1..m]CC_(n-1)
> +@end example
So the second key, with E_k2, is only ever used to encrypt the IV? If
you add a set_iv function, that could do this encryption and only store
E_k2(IV).
> --- /dev/null
> +++ b/xts.c
> @@ -0,0 +1,219 @@
[...]
> +static void
> +xts_shift(uint8_t *T)
> +{
> + uint8_t carry;
> + uint8_t i;
> +
> + for (i = 0, carry = 0; i < XTS_BLOCK_SIZE; i++)
> +{
> + uint8_t msb = T[i] & 0x80;
> + T[i] = T[i] << 1;
> + T[i] |= carry;
> + carry = msb >> 7;
> +}
> + if (carry)
> +T[0] ^= 0x87;
> +}
I think this is the same as block_mulx, in cmac.c. (Also same byte
order, right?)
Since the block size is fixed to 128 bits, I think it makes sense to use
the nettle_block16 type for all blocks but the application's src and
destination areas. Then we get proper alignment, and can easily use
operations on larger units.
BTW, for side-channel silence, we should change
if (carry)
T[0] ^= 0x87;
to something like
T[0] ^= 0x87 & - carry;
(and similarly for the cmac version).
> + fblen = length - (length % XTS_BLOCK_SIZE);
> + XTSENC(twk_ctx, T, tweak);
> +
> + /* the zeroth power of alpha is the initial ciphertext value itself, so we
> + * skip shifting and do it at the end of each block operation instead */
> + for (i = 0; i < fblen; i += XTS_BLOCK_SIZE)
> +{
In other places, loops like this are often written as
for (; length >= BLOCK_SIZE;
length -= BLOCK_SIZE, src += BLOCK_SIZE, dst += BLOCK_SIZE)
Then there's no need for the up-front division length & BLOCK_SIZE.
Doesn't matter much in this case, since the block size is a constant
power of two, but in general, division is quite expensive.
> + C = [i];
> + XTSCPY(P, [i]);
> + XTSXOR(P, T); /* P -> PP */
> + XTSENC(enc_ctx, C, P); /* CC */
> + XTSXOR(C, T); /* CC -> C */
I think it would be clearer with encf being an explicit argument to the
macros that need it (or maybe do it without the macros, if they expand
to only a single call each).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [WIP][PATCH][v2] Add fast constant-time ARM NEON ghash/gcm
"Yuriy M. Kaminskiy" writes: > From fa19a36985b7554517e9122b4cd193cd1a9c4f0e Mon Sep 17 00:00:00 2001 > From: "Yuriy M. Kaminskiy" > Date: Sun, 10 Mar 2019 11:08:46 +0300 > Subject: [PATCH] Add fast constant-time ARM NEON ghash/gcm > > Based on code from > https://conradoplg.cryptoland.net/software/ecc-and-ae-for-arm-neon/ > and > https://hal.inria.fr/hal-01506572 > Note: arm->neon is fast, neon->arm slow, so we delay bitreverse > (performed in arm) as much as possible and keep ctx->x and ctx->key > bitreversed. Thanks! I think I looked at the paper at some point, and it's clever. Some initial comments. Regarding bit-reversal, I think carryless multiplication is symmetric under bitreversal (reversing the two 8-bit inputs corresponds to bit-reversal of the 15-bit product), so unless input and output for some reason uses different bitorder, I hope it should be possible to do any needed bit reversal at key-setup only. > +.macro MUL64k3t4 rq rl rh ad bd k16 k32 k48 t0q t0l t0h t1q t1l t1h t2q t2l > t2h t3q t3l t3h Could you do these as m4 macros, like in the rest of the Nettle asm code? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] fat-arm.c: prefer getauxval() over /proc/cpuinfo parsing
"Yuriy M. Kaminskiy" writes:
> When compiled for armv6+ and getauxval() is present (glibc 2.16+),
> avoid slow and unreliable /proc/cpuinfo parsing.
>
> E.g. /proc/cpuinfo contains junk with qemu-user and can be unavailable
> in some chroot environment.
Do you know what's the preferred way to do this on android? Do we still
need /proc/cpuinfo, or are there any library facilities?
> +#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 16)
> +#include
This part could be an AC_CHECK_HEADERS([sys/auxv.h]) in configure.ac.
> +#if defined(AT_HWCAP) && defined(HWCAP_ARM_NEON)
> +#define HAVE_GETAUXVAL 1
> +#endif
> +#endif
> +
> #include "nettle-types.h"
>
> #include "aes-internal.h"
> @@ -87,6 +94,18 @@ get_arm_features (struct arm_features *features)
>}
>else
> {
> +#if defined(HAVE_GETAUXVAL) && __ARM_ARCH >= 6
Why the condition __ARM_ARCH >= 6? Is it because getauxval doesn't let us
make the distinction between arch_version 5 and 6?
> + unsigned long hwcap = getauxval(AT_HWCAP);
> + features->arch_version = __ARM_ARCH;
Is it important to take the compile-time arch into account? The effect
(when it makes a difference at all) will be to force use of certain
features, even if runtime checks say we're running on an older arch.
Is the getauxval method missing a way to get cpu arch at runtime? In the
docs
(https://github.com/torvalds/linux/blob/master/arch/arm/include/uapi/asm/hwcap.h)
I don't see anything corresponding to the "CPU arcitecture" line in
/proc/cpuinfo.
I'd be happier about getauxval if we could find a way to also get the
arch version without reading /proc/cpuinfo. But I don't think it's a
blocker for this change.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: nettle-stdint.h
Dmitry Eremin-Solenikov writes: >> > This file needs just uint8_t/uint64_t, so it might be easier to fix gnutls >> > to just include there. I'll open a MR. > > I'm sorry for the delay. I've opened > https://gitlab.com/gnutls/gnutls/merge_requests/901 . Excellent! And now the gnutls build in nettle's gitlab ci succeed. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
gitlab-ci builds (was: Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks)
ni...@lysator.liu.se (Niels Möller) writes: > I'm also considering adding a few more configurations to the ci, > including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. Done (but with -DNDEBUG, not -DNODEBUG). Seems to pass. For the fat builds, it would make some sense to run make check with some different settings for the NETTLE_FAT_OVERRIDE environment variable. What's available on the gitlab build machines? Fat builds are of interest for: x86_64 (native), where recognized keywords are vendor:intel/amd (used to select sse-based memxor), aesni and sha_ni, and arm, (32-bit, user-level qemu), where recognized keywords are arch: (distinction between armv6 and earlier) and neon. When I run qemu locally, all variants seem to be supported. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: sec_powm.c:293: GNU MP assertion failed: enb >= windowsize
ni...@lysator.liu.se (Niels Möller) writes: > That said, I'm about to delete nettle-stdint.h, and require that the > compiler supplies a (as was discussed quite a while ago). I've now merged changes to do that to the master-updates branch. It breaks the gnutls build, see https://gitlab.com/gnutls/nettle/-/jobs/149522724, In file included from gost/gost28147.c:40: gost/nettle-write.h:40:10: fatal error: nettle/nettle-stdint.h: No such file or directory #include ^~~~ Is this easy to fix (e.g., include nettle-types.h instead?), or should I add an installed header nettle/nettle-stdint.h containing only #include ? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [repost] [PATCH] Add --enable-fat support for arm neon chacha20
"Yuriy M. Kaminskiy" writes: > +DECLARE_FAT_FUNC(_nettle_chacha_core, chacha_core_func) > +DECLARE_FAT_FUNC_VAR(_chacha_core, chacha_core_func, c); > +DECLARE_FAT_FUNC_VAR(_chacha_core, chacha_core_func, neon); ^ The above underscores shouldn't be there. If I delete them, this works fine using debian's cross compilers and qemu. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [repost] [PATCH] Add --enable-fat support for arm neon chacha20
"Yuriy M. Kaminskiy" writes: > [PATCH] Add --enable-fat support for arm neon chacha20 Thanks, applied! Just pushed to the master-updates branch. When the currrent ARM assembly was written, it was benchmarked on cortex a9 and a15. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Jeffrey Walton writes: > My bad, I was speaking to the proposed -DNODEBUG macro presented earlier: Sorry for that typo; I intended to use the standard assert.h facility, i.e., -DNDEBUG. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Jeffrey Walton writes: > I recommend making folks explicitly ask for a debug build with > -DNETTLE_DEBUG or similar. "Debug build" vs "release build" is a bit alien to the way GNU packages are usually built, and I suspect it partly dates to times where optimization and useful debugging info were mutually exclusive. Default builds include both optimization and debugging symbols (and I think that's still what GNU coding standards recommend, perhaps with the option to strip debug symbols at install time). Regarding asserts, I generally recommend to build with asserts enabled. I know you disagree about that, but I really do *not* want any of us to repeast arguments on that topic on this list. Don't go that way. I'm happy to support builds with asserts turned off (that's the only reason I'm considering adding a ci builds for that configuration), but it's not going to be the default config. Not sure a --disable-asserts configura option is that useful, if it's only an alias for -DNDEBUG. What other effects do you suggest --disable-debug or --disable-assert should have? > Don't define it in terms of "not Posix NDEBUG " or "not Nettle > NODEBUG". I'm not following. As far as I understand, assert.h and NDEBUG are part of the C language, not Posix. (To go out on a tangent, there may be some projects where it's useful to include a *lot* of extra sanity code, and then have a way to exclude it for a "release" build. I think that's a bit rare, though, and I don't think Nettle is that type of project. I seem to recall one of the openbsd developers advocating always deleting the extra sanity check code and debug printfs after the code is in working state, before checking it in, to not distract from the actual code. In contrast to the fairly common practice to leave it in in under some #ifdef under the theory that it might be nice to have in some future debugging session. If it's really motivated to have that sanity check code in at all, because bugs are expected to have particularly subtle and hard-to-debug effects, one may well want that extra correctness assurance also when using the installed program in a "release" build). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Nikos Mavrogiannopoulos writes: > I attach a patch which moves everything to the latest images used by > gnutls (i.e., in addition to your patch, it also moves the x86 builds > to debian). Merged now. And I've deleted eratosthens.c. We'll see how to deal with the static analalyzer's remaining complaints on eccdata.c. I'm also considering adding a few more configurations to the ci, including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. Anything I have to keep in mind (e.g., limits on builder resources?) Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
