Red writes:
> other than the usual cross-compilation dance with --host, we only pass
> --disable-fat. wget, curl and many other things are built against
> gnutls and nettle in turn and work as one would expect.
I see. I think x86_64 fat builds should work fine on windows.
Did you get problems
While trying to improve organization of SIV-mode tests (and AEAD in
general), I noticed that SIV-CMAC currently doesn't support in-place
operation (src == dst). That's unlike more or less all other encryption
mechanisms in Nettle.
That needs to be either fixed, or properly documented. I think addi
I've now merged OCB support to the master branch. Some changes from the
development branch:
* I added space for one extra block to struct ocb_key (making it 64
bytes rather than 48). Currently unused, but available for future
optimization.
* I moved the corresponding nettle_aead struct to an
Gisle Vanem writes:
> But I noted it's .asm-code says 'W64_ENTRY(3, 0)'
> Why not 'W64_ENTRY(4, 0)' when there are 4 arguments?
>
> I admin 'm4' is alien to me, but changing it into:
>
> --- a/x86_64/sha256-compress-n.asm 2023-02-13 07:38:45
> +++ b/x86_64/sha256-compress-n.asm 2023-02-14 14:04:2
r...@foxi.me writes:
> do I need to say anything?
Please do, to provide a bit of context. I'm not at all familiar with
midipix. Some questions:
1. Is this aimed for native (windows) builds, or cross builds, or both?
2. How does shared library linking differ from mingw32/sygwin case, and
from
Gisle Vanem writes:
>> It would also be nice to setup some windows tests in the ci system
>> (which runs on a repo mirror at
>> https://gitlab.com/gnutls/nettle/-/pipelines), cross-compile + wine would
>> be the easiest for me to setup, but I think there are also some windows
>> "runners" that co
Gisle Vanem writes:
> Running 'nettle-benchmark.exe' gave me a crash in some
> .asm-code I failed to understand. It's signature is:
> _nettle_sha256_compress_n (uint32_t *state, const uint32_t *k,
> size_t blocks, const uint8_t *input);
>
> But I noted it's .asm-code
Niels Möller writes:
> My current understanding is that the most important improvement over the
> initial implementation is to call the underlying block cipher with more
> than one block at a time (enabling parallelism on some hardware, and
> reducing overhead).
I've kept doing this, but going
Simon Josefsson writes:
> This is a bit of a mess, unfortunately, and one solution may be to
> implement a non-solution approach: instead of changing the sign or
> verify operations,
As far as I'm aware, there's no need to modify the signing operation, am
I missing something? Do the details of s
Hi,
A few weeks ago, I stumbled on
https://hdevalence.ca/blog/2020-10-04-its-25519am. Summary: The
specification for Ed25519 signatures, RFC 8032, doesn't specify
unambiguously which bit strings are valid signatures, and which aren't.
And implementations differ on the details.
This could matter i
ni...@lysator.liu.se (Niels Möller) writes:
> A nettle release reasonable soon would be good, but I'm afraid it will
> be a bit tight to fit to the debian schedule. In the best case, we could
> have a release out around new year or early January. I guess it likely
> counts as a "transition", even
11 matches
Mail list logo
