Niels Möller writes:
> Below patch seems to fix this issue, but not entirely sure that's the
> way I want to do it.
I've pushed a fix, along the same lines, see
https://git.lysator.liu.se/nettle/nettle/-/commit/99e62003c3916fdef04a2d3327281f8f498b609e
I believe that should fix all hash update
Niels Möller writes:
>> This is similar to this issue:
>> https://gitlab.com/gnutls/gnutls/-/issues/1306
>> where we passed NULL to sha*_update in the GnuTLS code, though it turned
>> to be a non-issue.
>
> I don't remember seeing that issue. I think it should be allowed to call
> sha*_update
Daiki Ueno writes:
> Niels Möller writes:
>> One failure is the new side-channel test failing with mini-gmp. Which is
>> expected, the test should just be skipped in mini-gmp builds (similar to
>> several other sc tests).
>
> Yes, I'm attaching the patch for this.
I've committed and pushed
Niels Möller writes:
> I noticed that there are two failures in the ci builds. See
> https://gitlab.com/gnutls/nettle/-/pipelines/1178451395.
>
> One failure is the new side-channel test failing with mini-gmp. Which is
> expected, the test should just be skipped in mini-gmp builds (similar to
>
Daiki Ueno writes:
> That said, I agree that it would be more user friendly to combine them
> and treat it as a regular error, as we do in pss_encode_mgf1.
Thanks for the update, patch merged.
I noticed that there are two failures in the ci builds. See
Hello Niels,
Thank you for merging it and the suggestions.
Niels Möller writes:
> Thanks to the doc update, I now noticed the possibility of failure from
> the encryption functions. Failure is propagated from _oaep_encode_mgf1,
> which does
>
> assert (key_size >= 2 * hash->digest_size - 2);
Daiki Ueno writes:
> Thank you; I have addressed those issues. As for the merging, I think
> it is ready now.
Thanks, merged.
Thanks to the doc update, I now noticed the possibility of failure from
the encryption functions. Failure is propagated from _oaep_encode_mgf1,
which does
assert
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
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
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. This is an unusually busy week for me, so I'm afraid I'll not be
able to look at this (or any of the other pendning
Niels Möller writes:
> Daiki Ueno writes:
>
>> Added `mark_bytes_undefined (1, [key->size]);` to the test
>> cases doing encryption.
>
> I'm afraid that isn't right. For one, mark_bytes_undefined is
> conditioned so it only has any effect when running the sc tests. Second,
> it will not produce
Daiki Ueno writes:
> Added `mark_bytes_undefined (1, [key->size]);` to the test
> cases doing encryption.
I'm afraid that isn't right. For one, mark_bytes_undefined is
conditioned so it only has any effect when running the sc tests. Second,
it will not produce any warnings for writes, which I
Niels Möller writes:
> Daiki Ueno writes:
>
>> The zip file is no longer accessible, but I still keep a copy and it
>> seems identical to the one at:
>> https://github.com/pyca/cryptography/tree/main/vectors/cryptography_vectors/asymmetric/RSA/pkcs-1v2-1d2-vec
>>
>> Is it OK to use the vector
Daiki Ueno writes:
> The zip file is no longer accessible, but I still keep a copy and it
> seems identical to the one at:
> https://github.com/pyca/cryptography/tree/main/vectors/cryptography_vectors/asymmetric/RSA/pkcs-1v2-1d2-vec
>
> Is it OK to use the vector assuming it is public domain?
Hello,
Niels Möller writes:
> Daiki Ueno writes:
>
* For tests, would it make some with some test that check that
encryption with a given message and randomness gives the expected
output? Even better if there are any authoritative testcases for that?
>>
>> I would be happy
Daiki Ueno writes:
>>> * For tests, would it make some with some test that check that
>>> encryption with a given message and randomness gives the expected
>>> output? Even better if there are any authoritative testcases for that?
>
> I would be happy to add if there are any, even if they
Hello Niels, Simo,
Thanks for the comments. I've updated MR addressing part of them (see
inline for the details).
Simo Sorce writes:
> On Mon, 2024-01-15 at 21:43 +0100, Niels Möller wrote:
>> Thanks, I've had a look, and it looks pretty good to me. Some comments
>> and questions:
>>
>> *
On Mon, 2024-01-15 at 21:43 +0100, Niels Möller wrote:
> Daiki Ueno writes:
>
> > Now that another attack on RSA encryption with PKCS#1 v1.5 padding has
> > been discovered (though Nettle is not vulnerable)[1], it is recommended
> > to avoid using the v1.5 scheme in new applications[2][3], and
Daiki Ueno writes:
> Now that another attack on RSA encryption with PKCS#1 v1.5 padding has
> been discovered (though Nettle is not vulnerable)[1], it is recommended
> to avoid using the v1.5 scheme in new applications[2][3], and thus
> supporting RSA-OAEP in Nettle is becoming more relevant.
I
Hello Nicolas, Niels,
Now that another attack on RSA encryption with PKCS#1 v1.5 padding has
been discovered (though Nettle is not vulnerable)[1], it is recommended
to avoid using the v1.5 scheme in new applications[2][3], and thus
supporting RSA-OAEP in Nettle is becoming more relevant.
I made
Hello again,
After rethinking it, I refactored the new functions to be consistent
with how Nettle functions are designed, now there's one encrypt/decrypt
function per hash.
https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20
The new functions are the following:
Encryption:
int
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
22 matches
Mail list logo
