Hubert Kario via Gcrypt-devel wrote:
On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote:
Hubert Kario wrote:
Actually no. If the time slots are consistent (say, the USB device
returns
the message only on the second, on the dot), then the attacker can
tune the
time when it _starts_ th
NIIBE Yutaka wrote:
Hello,
Jacob Bachmeyer wrote:
Otherwise, a non-standard malicious host could "bend" the slot timing
enough that the fixed response delay is not always sufficient for the
operation to complete.
True. Thank you for showing this possibility. I didn't consider this
Werner Koch via Gcrypt-devel wrote:
Hi!
On Wed, 17 Apr 2024 11:57, Simon Josefsson said:
[...]
Are pre-C99 compilers supported for real, or is this merely an obsolete
desired feature? Do you have any example of a pre-C99 compiler that can
[...] But struct initializers and trailing comm
On 2/6/25 23:28, NIIBE Yutaka via Gcrypt-devel wrote:
Hello,
This is not related to modular exponentiation, but another function for
constant-time; MPI comparison by a helper function.
I think that this implementation could be improved. Anyhow, let us
start having the function for comparison.
On 2/9/25 08:06, Jussi Kivilinna wrote:
Hello,
On 9.2.2025 0.50, Jacob Bachmeyer via Gcrypt-devel wrote:
On 2/7/25 20:05, NIIBE Yutaka via Gcrypt-devel wrote:
NIIBE Yutaka wrote:
I think that this implementation could be improved.
I should use ct_limb_gen_inv_mask function instead of
On 2/7/25 20:05, NIIBE Yutaka via Gcrypt-devel wrote:
NIIBE Yutaka wrote:
I think that this implementation could be improved.
I should use ct_limb_gen_inv_mask function instead of directly use unary
minus operator.
Could it make more sense to write:
result &= ct_limb_gen_inv_mask (gt) & ct_l
On 2/13/25 23:41, Jussi Kivilinna wrote:
On 14.2.2025 6.57, Jacob Bachmeyer via Gcrypt-devel wrote:
[...]
If I read this correctly, the carry handling is depending on integer
overflow wrapping around, which is not actually defined behavior in
C, although most platforms do handle it that way
On 2/14/25 00:00, NIIBE Yutaka wrote:
Hello,
Jacob Bachmeyer wrote:
Also, if I understand correctly from the previous discussion, "<" is to
be avoided because compilers can use a branch to implement it.
Than you. Good catch. It is the reason why we have
mpih_ct_limb_less_than.
You are wel
On 2/13/25 19:25, NIIBE Yutaka via Gcrypt-devel wrote:
Hello,
This change introduces a function _gcry_mpih_add_1_lli for one limb
addition with least leak.
diff --git a/mpi/mpi-inline.h b/mpi/mpi-inline.h
index 090e8a94..6954affb 100644
--- a/mpi/mpi-inline.h
+++ b/mpi/mpi-inline.h
@@ -68,6 +68
On 2/13/25 23:01, NIIBE Yutaka via Gcrypt-devel wrote:
Hello,
This change introduces a function _gcry_mpih_table_lookup. The idea is
accessing the whole table entries (so that cache timing won't possible)
and select the value by ct_limb_select.
Your suggestions/comments for the implementation
On 3/27/25 00:19, NIIBE Yutaka via Gcrypt-devel wrote:
* mpi/ec.c (add_points_weierstrass_a, add_points_edwards_a): New.
(mpi_ec_mul_point_lli): Use those routines directly.
Found a typo: "P1 is never same to P1"?
-- Jacob
___
Gcrypt-devel mailin
On 3/26/25 19:06, NIIBE Yutaka via Gcrypt-devel wrote:
[...] For the first improvement,
I realized that runtime checks in ec_mod and its friends could be leaky,
because it depends on how small/big the value is.
Could these checks instead be improved to run in constant time?
Since it is (or c
On 3/27/25 20:21, NIIBE Yutaka wrote:
[...]
Because we expose the lower level API, it is possible for an application
to violate the preconditions, by supplying an ECC point with larger MPIs.
By the violation of the preconditions, it used to result the call of
log_bug (emitting a message and abo
On 2/17/25 23:30, NIIBE Yutaka wrote:
Hello,
Thank you for your comments.
You are welcome.
Jacob Bachmeyer wrote:
[...]
There might also be architecture-specific instructions that can be used
to retrieve a table row without polluting the data cache; allowing
architecture-specific overrides
On 3/28/25 08:11, Ian Goldberg via Gcrypt-devel wrote:
On Fri, Mar 28, 2025 at 10:21:43AM +0900, NIIBE Yutaka via Gcrypt-devel wrote:
While, arbitrary integers can be represented in the MPI representation,
for a specific curve, the finite field is the one of integers module P
(P: a prime defined
On 6/24/25 20:36, NIIBE Yutaka via Gcrypt-devel wrote:
* src/gcrypt.h.in (GCRY_KEM_RAW_P256K1): New.
* cipher/kem-ecc.c (algo_to_curve, algo_to_seckey_len): Support
GCRY_KEM_RAW_P256K1.
Possible typo? The entry for GCRY_KEM_RAW_P256K1 (39) is commented
"SECP256R1". Is that correct? Should i
On 6/18/25 11:53, Paul Eggert wrote:
On 2025-06-17 20:27, Jacob Bachmeyer via Gcrypt-devel wrote:
It is a size_t so it is unsigned.
Then the checks are correct as written.
Not on oddball platforms where SIZE_MAX <= INT_MAX, because in that
case it's signed integer overflow and beh
On 6/17/25 00:31, NIIBE Yutaka via Gcrypt-devel wrote:
* cipher/pubkey-util.c (_gcry_pk_util_data_to_mpi): Remove bogus check
for VALUELEN.
NACK! NACK! NACK!
Those are checks for integer overflow. (They may even be correct if
VALUELEN is unsigned.)
If VALUELEN is a signed type, they are
On 6/17/25 21:20, Collin Funk wrote:
Jacob Bachmeyer via Gcrypt-devel writes:
NACK! NACK! NACK!
Those are checks for integer overflow. (They may even be correct if
VALUELEN is unsigned.)
If VALUELEN is a signed type, they are undefined behavior and need to
be fixed, not removed.
It is a
On 6/26/25 00:10, NIIBE Yutaka via Gcrypt-devel wrote:
* tests/t-common.h (read_textline): Increase the buffer size.
I understand that this is testsuite code, so a fixed stack buffer is not
the serious problem it could otherwise be, but why not replace the fixed
buffer with a heap-allocated b
On 5/13/25 23:35, NIIBE Yutaka via Gcrypt-devel wrote:
* src/mpi.h (_gcry_mpi_assign_limb_space): Add.
(_gcry_mpih_mod_lli, _gcry_mpih_mul_lli): Add.
* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Take care
about least leak with k^(-1).
--
GnuPG-bug-id: 7519
Signed-off-by: NIIBE Yutaka
---
cip
On 9/27/25 02:02, Jussi Kivilinna wrote:
* cipher/mceliece6688128f.c (pk_gen): Remove 'mat' array allocation and
rename function to ...
(pk_gen_mat): ... this.
(pk_gen): New wrapper for 'pk_gen_mat' with dynamic allocation of 'mat'
array.
--
Huge array allocations from stack are not always guara
On 9/27/25 01:16, Jussi Kivilinna wrote:
Hello,
[...]
[...] About memory zeroing in general... I see that PQ algorithms use
quite a lot of stack arrays in their implementations (some quite large
allocations too) but there is no stack memory wiping in place. Maybe
there should be? I guess sim
On 9/26/25 01:53, Jussi Kivilinna wrote:
* cipher/mceliece6688128f.c (pk_gen): Remove 'mat' array allocation and
rename function to ...
(pk_gen_mat): ... this.
(pk_gen): New warper for 'pk_gen_mat' with dynamic allocation of 'mat' array.
Typo? Did you mean "wrapper"?
Why do it this way instea
On 9/30/25 01:30, Jussi Kivilinna wrote:
Hello,
On 27/09/2025 10:54, Jussi Kivilinna wrote:
* cipher/mceliece6688128f-patches: New.
* cipher/mceliece6688128f.sh: Apply patches from
'cipher/mceliece6688128f-patches/*'.
--
I had to drop this commit with patch files as git server rejects this
w
On 10/1/25 10:57, Jussi Kivilinna wrote:
On 01/10/2025 04:26, Jacob Bachmeyer via Gcrypt-devel wrote:
On 9/30/25 01:30, Jussi Kivilinna wrote:
Hello,
On 27/09/2025 10:54, Jussi Kivilinna wrote:
* cipher/mceliece6688128f-patches: New.
* cipher/mceliece6688128f.sh: Apply patches from
'c
26 matches
Mail list logo
