On Friday, 25 August 2023 14:02:51 CEST, Niels Möller wrote:
Hubert Kario writes:
On Friday, 25 August 2023 07:51:10 CEST, Niels Möller wrote:
Thus, I think it's more of a documentation issue than code issue:
it will be much better to just say that mpz_powm_sec() is not usable for
> Therefore,
> additional layers of side-channel obfuscation is needed, like standard
> RSA message blinding, mod argument blinding, exponent blinding.
sure, but I think that should be performed by upper level code, as how
you do blinding depends on the algorithm and operation you're
On Friday, 25 August 2023 12:14:46 CEST, Torbjörn Granlund wrote:
marco.bodr...@tutanota.com writes:
This sounds not too complex to do. Even if, as usual, C code
is prone to compiler optimizations...
I think this is a good idea.
The concern for compilers messing up secure code is very
On Friday, 25 August 2023 14:02:51 CEST, Niels Möller wrote:
Hubert Kario writes:
On Friday, 25 August 2023 07:51:10 CEST, Niels Möller wrote:
And that's for all inputs? Nice.
Well, not all, I mostly tested ones that had obvious patterns, like
zero to power zero, 0xff to power 0xff, full
On Friday, 25 August 2023 07:51:10 CEST, Niels Möller wrote:
Hubert Kario writes:
I was able to confirm that the low-level functions, like the
mpn_sec_powm()
function have no timing leakage with regards to operands or result
(exactly like section 8.1 of the manual[2] states).
And that's
Hubert Kario writes:
> On Friday, 25 August 2023 07:51:10 CEST, Niels Möller wrote:
>> And that's for all inputs? Nice.
> Well, not all, I mostly tested ones that had obvious patterns, like
> zero to power zero, 0xff to power 0xff, full word to power of 1, full
> word to power (mod-1), etc. All
Niels Möller writes:
I know you've done more work on that recently, while I have no idea how
"mod argument blinding" works...
A random ring extension. Yes, mod argument invariance will still be
there, unless one changes extension for each multiply/squaring inside
the modexp loop, but an
Torbjörn Granlund writes:
> We should probably exclude certain sec_ functions when not all sensitive
> functions are provided in asm, and thereby as a result of
> --disable-assembly? We should in essence not provide C versions of
> e.g., mpn_sec_tabselect.
I would suggest testing of side
marco.bodr...@tutanota.com writes:
This sounds not too complex to do. Even if, as usual, C code is prone to
compiler optimizations...
I think this is a good idea.
The concern for compilers messing up secure code is very valid. An
example is that clang makes our mpn_sec_tabselect useless by
marco.bodr...@tutanota.com writes:
>> 1. Document that the mpz_t result from mpz_powm_sec always has an alloc
>> size >= n, where n is the limb size of the modulo input, and that the
>> limb array is zero padded up to n.
>>
>
> You write ">= n" and not "=n" because if it was larger we avoid to
>
Ciao,
25 ago 2023, 08:11 da ni...@lysator.liu.se:
> Niels Möller writes:
>
>> It's preferable to use the mpn_powm_sec. When using mpz_t, I see no
>> reasonable to avoid leakage of the normalized size (or number of
>> all-zero limbs at the most significant end).
>>
> One possibly unreasonable
Niels Möller writes:
> It's preferable to use the mpn_powm_sec. When using mpz_t, I see no
> reasonable to avoid leakage of the normalized size (or number of
> all-zero limbs at the most significant end).
One possibly unreasonable approach for consideration:
1. Document that the mpz_t result
Hubert Kario writes:
> I was able to confirm that the low-level functions, like the mpn_sec_powm()
> function have no timing leakage with regards to operands or result
> (exactly like section 8.1 of the manual[2] states).
And that's for all inputs? Nice. (I think an earlier version used a
Hello,
While I was researching CVE-2022-4304 in OpenSSL, I looked into some other
implementations (specifically to see if there are constant-time
implementations
of modular arithmetic).
I was able to confirm that the low-level functions, like the mpn_sec_powm()
function have no timing leakage
14 matches
Mail list logo
