Re: Add RSA-OAEP encryption/decryption to Nettle
Niels Möller writes: > Daiki Ueno writes: > >> Sorry for the confusion and thank you for the explanation; now I get it. >> I pushed a change along the of option (2). Could you take a look again? > > Thanks, looks good! Two nits, and let me know at which point you'd like > to get it merged, and do further improvements as followup MRs. Thank you; I have addressed those issues. As for the merging, I think it is ready now. I have also created a draft MR in GnuTLS to use the algorithm in PKCS#8, etc., so we can test the implementation in a broader context: https://gitlab.com/gnutls/gnutls/-/merge_requests/1805 > Since the oaep.h header now only declares internal functions, it > shouldn't be installed (moved from HEADERS to DISTFILES in Makefile.in). > > And it would be nice if the manual could give some more detail about the > label: As I understnd it, the label is optional, so it's fine to pass 0, > NULL if not needed. And if used, the same label must be used for both > encrypt and decrypt. Regards, -- Daiki Ueno ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: reply: reply: A new realization of ecc-sm2
"zhongxuan (A)" writes: > Yes, I've tried to make a fork in > https://git.lysator.liu.se/nettle/nettle/-/forks/new but failed, it > just reports ' An error occurred while forking the project. Please try > again. '. Sorry, I don't really know how to troubleshoot. Maybe you can try if it works better on the mirror repo at https://gitlab.com/gnutls/nettle? I've had a new look at your latest patch. I'm not at all familiar with sm2, and I'm hoping I don't have to fully understand all details, but I am a bit confused. I think one important part of your patch is about adding support for Weierstrass curves with a different constant than a = -3. And then I look at the spec at https://datatracker.ietf.org/doc/html/draft-shen-sm2-ecdsa to see how the curve really is defined. It looks like that document gives several examples of curves, including one named "Fp-256", but the one that it looks like you are defining, in eccdata.c, is the one defined in Appendix D "Recommended parameters". So my first question: Is "sm2" an appropriate name for a single curve, or is there some more specific name for the curve in Appendix D that you use? Second question, when I look at that curve, it is defined like this: :A elliptic curve on a prime field of 256 bits is recommended: : : :y^2 = x^3 + ax + b : : : p=FFFE : a=FFFE FFFC : b=28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93 : n=FFFE 7203DF6B 21C6052B 53BBF409 39D54123 : Gx=32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7 : Gy=BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0 But for this parameters, we have a = p - 3 = -3 (mod p), like for all other Weierstrass curves currently supported by Nettle! Which is good news, since then the same point addition functions can be used, but it also means that maybe you have done some work that isn't really needed? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: ppc64 micro optimization
Danny Tsen writes:
> Here is the new patch v4 for AES/GCM stitched implementation and
> benchmark based on the current repo.
Thanks. I'm not able to read it all carefully at the moment, but I have
a few comments, see below.
In the mean time, I've also tried to implement something similar for
x86_64, see branch x86_64-gcm-aes. Unfortunately, I get no speedup, to
the contrary, my stitched implementation seems considerably slower...
But at least that helped me understand the higher-level issues better.
> --- a/gcm-aes128.c
> +++ b/gcm-aes128.c
> @@ -63,14 +63,30 @@ void
> gcm_aes128_encrypt(struct gcm_aes128_ctx *ctx,
> size_t length, uint8_t *dst, const uint8_t *src)
> {
> - GCM_ENCRYPT(ctx, aes128_encrypt, length, dst, src);
> + size_t done = _gcm_aes_encrypt (&ctx->key, &ctx->gcm.x.b, &ctx->gcm.ctr.b,
> + _AES128_ROUNDS, &ctx->cipher.keys, length,
> dst, src);
I know I asked you to explode the context into many separate arguments
to _gcm_aes_encrypt. I'm now backpedalling a bit on that. For one, it's
not so nice to have so many arguments that they can't be passed in
registers. Second, when running a fat build on a machine where the
needed instructions are unavailable, it's a bit of a waste to have to
spend lots of instructions on preparing those arguments for calling a
nop function. So to reduce overhead, I'm now leaning towards an
interface like
/* To reduce the number of arguments (e.g., maximum of 6 register
arguments on x86_64), pass a pointer to gcm_key, which really is a
pointer to the first member of the appropriate gcm_aes*_ctx
struct. */
size_t
_gcm_aes_encrypt (struct gcm_key *CTX,
unsigned rounds,
size_t size, uint8_t *dst, const uint8_t *src);
That's not so pretty, but I think that is workable and efficient, and
since it is an internal function, the interface can be changed if this
is implemented on other architectures and we find out that it needs some
tweaks. See
https://git.lysator.liu.se/nettle/nettle/-/blob/x86_64-gcm-aes/x86_64/aesni_pclmul/gcm-aes-encrypt.asm?ref_type=heads
for the code I wrote to accept that ctx argument.
It would also be nice to have a #define around the code calling
_gcm_aes_encrypt, so that it is compiled only if (i) we have an
non-trivial implementation of _gcm_aes_encrypt, or (ii) we're a fat
build, which may select a non-trivial implementation of _gcm_aes_encrypt
at run time.
> + ctx->gcm.data_size += done;
> + length -= done;
> + if (length > 0) {
Not sure of the check for length > 0 is needed. It is fine to call
gcm_encrypt/GCM_ENCRYPT with length 0. There will be some overhead for a
call with length 0, though, which may be a more common case when
_gcm_aes_encrypt is used?
> +define(`SAVE_GPR', `std $1, $2(SP)')
> +define(`RESTORE_GPR', `ld $1, $2(SP)')
I think the above two macros are unneeded, it's easier to read to use
std and ld directly.
> +define(`SAVE_VR',
> + `li r11, $2
> + stvx $1, r11, $3')
> +define(`RESTORE_VR',
> + `li r11, $2
> + lvx $1, r11, $3')
It would be nice if we could trim the use of vector registers so we
don't need to save and restore lots of them. And if we need two
instructions anyway, then maybe it would be clearer with PUSH_VR/POP_VR
that also adjusts the stack pointer, and doesn't need to use an additional
register for indexing?
> +C load table elements
> +li r9,1*16
> +li r10,2*16
> +li r11,3*16
> +lxvd2x VSR(H1M),0,HT
> +lxvd2x VSR(H1L),r9,HT
> +lxvd2x VSR(H2M),r10,HT
> +lxvd2x VSR(H2L),r11,HT
> +li r9,4*16
> +li r10,5*16
> +li r11,6*16
> +li r12,7*16
> +lxvd2x VSR(H3M),r9,HT
> +lxvd2x VSR(H3L),r10,HT
> +lxvd2x VSR(H4M),r11,HT
> +lxvd2x VSR(H4L),r12,HT
I think it would be nicer to follow the style I tried to implement in my
recent updates, using some registers (e.g., r9-r11) as offsets,
initializing them only once, and using everywhere. E.g., in this case,
the loading could be
lxvd2x VSR(H1M),0,HT
lxvd2x VSR(H1L),r9,HT
lxvd2x VSR(H2M),r10,HT
lxvd2x VSR(H2L),r11,HT
addi HT, HT, 64
lxvd2x VSR(H3M),0,HT
lxvd2x VSR(H3L),r9,HT
lxvd2x VSR(H4M),r10,HT
lxvd2x VSR(H4L),r11,HT
> +C do two 4x ghash
> +
> +C previous digest combining
> +xxlor vs0, VSR(S0), VSR(S0)
> +vxor S0,S0,D
> +
> +GF_MUL(F2, R2, H3L, H3M, S1)
> +GF_MUL(F, R, H4L, H4M, S0)
> +vxor F,F,F2
> +vxor R,R,R2
> +
> +xxlor VSR(S0), vs0, vs0
> +
> +GF_MUL(F3, R3, H2L, H2M, S2)
> +GF_MUL(F4, R4, H1L, H1M, S3)
> +vxor F3,F3,F4
> +vxor R3,R3,R4
> +
> +vxor F,F,F3
> +vxor D,R,R3
> +GHASH_REDUCE(D, F, POLY_L, R2, F2) C
Re: Add RSA-OAEP encryption/decryption to Nettle
Daiki Ueno writes: > Sorry for the confusion and thank you for the explanation; now I get it. > I pushed a change along the of option (2). Could you take a look again? Thanks, looks good! Two nits, and let me know at which point you'd like to get it merged, and do further improvements as followup MRs. Since the oaep.h header now only declares internal functions, it shouldn't be installed (moved from HEADERS to DISTFILES in Makefile.in). And it would be nice if the manual could give some more detail about the label: As I understnd it, the label is optional, so it's fine to pass 0, NULL if not needed. And if used, the same label must be used for both encrypt and decrypt. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
