Hello,
I've made a new Merge Request in the nettle gitlab repo to provide
RSA-OAEP encryption and decryption:
https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20
It adds 2 new functions:
int
pkcs1_oaep_encrypt (size_t key_size,
void *random_ctx, nettle_random_func *random,
size_t hlen,
size_t label_length, const uint8_t *label,
size_t message_length, const uint8_t *message,
mpz_t m);
int
pkcs1_oaep_decrypt (size_t key_size,
const …
[View More]mpz_t m,
size_t hlen,
size_t label_length, const uint8_t *label,
size_t *length, uint8_t *message);
The parameter hlen is the output length of the SHA function used for
masking data:
- SHA1_DIGEST_SIZE
- SHA256_DIGEST_SIZE
- SHA384_DIGEST_SIZE
- SHA512_DIGEST_SIZE
Is it possible to get feedback for this MR and eventually push it to the
master branch?
Thanks in advance
/Nicolas
[View Less]
Hello,
we (Sequoia PGP) would love to see OCB being implemented in Nettle. The
OpenPGP working group is working on a revision of RFC4880, which will
mostly be a cryptographic refresh, and will bring AEAD to OpenPGP.
The previous -now abandoned- draft called for EAX being mandatory, and
OCB being optional [0]. This was motivated by OCB being encumbered by
patents. However, said patents were waived by the holder [1].
0: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#…
[View More]sect…
1: https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/
With OCB being no longer patent-encumbered, it seems preferable over the
two-pass EAX construction. Therefore, it seems plausible that the WG
makes OCB mandatory to implement. To support that in Sequoia, we'd need
support for that in Nettle (Nettle is our main cryptographic backend).
Unfortunately, we don't have the expertise in our team to contribute a
patch, and we currently aren't in a position to offer funding for the
implementation.
Thanks,
Justus
[View Less]
On Wed, Aug 18, 2021 at 11:38 PM Stijn Tintel <stijn(a)linux-ipv6.be> wrote:
> On 18/08/2021 22:29, Maamoun TK wrote:
> > On Tue, Aug 17, 2021 at 9:40 AM Niels Möller <nisse(a)lysator.liu.se
> > <mailto:nisse@lysator.liu.se>> wrote:
> >
> > The configuration where it didn't work was
> > powerpc64-openwrt-linux-musl. I'd like Nettle to work on embedded
> > systems whenever practical. But support depends on assistance from
> …
[View More]> users
> > of those systems.
> >
> > As I understood it, this system needs to use the v2 ABI. I would hope
> > it's easy to detect the abi used by the configured C compiler, and
> > then
> > select the same prologue sequence as is currently used for
> > little-endian. I.e., one more configure test, and changing the
> > "ifelse(WORDS_BIGENDIAN,no," condition in powerpc64/machine.m4 to
> > check
> > a different configure variable.
> >
> >
> > I skipped processing the assembly files with a different approach, I
> > made the configuration check for musl and endianness variant to
> > trigger assembly processing. You can check the fix in this branch
> > https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix
> > <https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix>
> > Apparently, the bug reporter uses a cross-compiler for powerpc arch.
> > It would be great to run this fix at the same bug environment since I
> > tested the patch in different circumstances.
>
> Your patch has no effect in my environment (OpenWrt build system), as
> host_os is linux-gnu, according to config.log, so it doesn't match
> *musl. See [1] for config.log and [2] for full compile log.
>
> The output of powerpc64-openwrt-linux-musl-gcc -E -dM - </dev/null |
> sort, which was requested earlier in this thread can be seen at [3].
>
> Thanks,
> Stijn
>
> [1] https://gist.github.com/9e0ecb025033dda1d0d58094da84c308
> [2] https://gist.github.com/stintel/0e7046df511cf4d1ca20edb56df50b1b
> [3] https://gist.github.com/stintel/b3651a7db87edea9e8bd0aef242bcdae
config.guess detects the C standard library based on a result from the
compiler defined in "CC_FOR_BUILD" variable, for some reason OpenWrt build
system failed to set that variable properly, from your config.log I can see
CC_FOR_BUILD='gcc -O -g' but when I use bare musl tools I get
CC_FOR_BUILD='musl-gcc'
There is nothing specific in the output of powerpc64-openwrt-linux-musl-gcc
-E -dM log as I can see. In musl libc FAQ, they stated that there is no
__MUSL__ in the preprocessor macros https://wiki.musl-libc.org/faq.html
regards,
Mamone
[View Less]
I'm looking at implementing elliptic curve point compression a la SEC1
(admittedly, mostly to reduce the number of "feature not supported" code
paths in a library, but it seems like a somewhat useful ability).
Nettle/Hogweed already implements it internally for curve25519, but I want
to implement it for the "secp" curves as well.
Point compression is easy enough, but point decompression requires some
curve math, potentially dependent on the specific curve, and some of it is
redundant …
[View More]with what's already done in ecc_point_set(). 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.
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?
[View Less]