[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] Constant-timedness of hex encoding/decoding
From:       David Hook <dgh () cryptoworkshop ! com>
Date:       2022-04-05 0:13:55
Message-ID: ea0bfaf8-9238-7a9b-355a-b84a8b6925aa () cryptoworkshop ! com
[Download RAW message or body]

Hi,

It was done by analysis. You'll find the attribution in the contributors 
file in the entry associated with CVE-2016-1000339.

That said, we are interested in anything which would improve the 
security of the libraries.

Regards,

David

On 4/4/22 21:19, Karolin Varner wrote:
> Morning,
>
> thank you for the explanation!
>
> Is this switching idea based on some published analysis or is this a 
> novel solution?
> Inspecting the code, it seems to me that the usage pattern is fixed, 
> so from a purely
> theoretical perspective this should produce a predicatble timing pattern.
>
> The purpose of these primitives is to provide a very high level of 
> security on a very sound theoretical foundation;
> timing attack resistant implementations are part of that foundation, 
> while mitigations just move the goalposts for attackers.
>
> And if people really need very high speed crypto, they probably should 
> be using an implementation that utilizes AES-NI or SSE3…
>
> Best,
> Karolin
>
> On 4/2/22 06:00, David Hook wrote:
>>
>> AESFastEngine is marked as deprecated due to side channels, as might 
>> be expected these are timing based.
>>
>> AESEngine clones the sbox and then switches between the clone and the 
>> static one. It's been found that this creates enough noise in the 
>> timing that trying to guesstimate the key based on the cipher's 
>> lookups is too difficult. Cost was about 10%, which at the time still 
>> put it ahead of moving to a bit sliced implementation.
>>
>> That said, it's probably about time we revisited this, maybe things 
>> have improved...
>>
>> Regards,
>>
>> David
>>
>> On 1/4/22 22:57, Karolin Varner wrote:
>>> Hi Matt,
>>>
>>> thanks for your response! I was asking because I need a constant 
>>> time implementation for an application;
>>> I was able to solve my use case by writing a constant time 
>>> implementation myself so that's solved!
>>>
>>> In regards to bouncycastle, I haven't inspected the code but using 
>>> non constant-time code in initializers might still be an issue
>>> unless steps are taken to prohibit use of these initializers in 
>>> response to outside queries as those uses could still result in
>>> timing oracles.
>>>
>>> When it comes to implenmenting Substitution-Permutation networks in 
>>> a constant time fashion, I believe the modern way to do it is using
>>> bitslicing[0].
>>>
>>> Is AES implemented in a constant-time fashion in bouncycastle? 
>>> Inspecting AESEngine, AESFastEngine and AESLightEngine I see lookup 
>>> tables
>>> in each with accesses based on the WorkingKey/KW variable as well as 
>>> the round variables?
>>>
>>> Best,
>>> Karolin
>>>
>>> [0]: 
>>> https://www.ru.nl/publish/pages/769526/z_kostas_papagiannopoulos.pdf
>>>
>>> On 4/1/22 12:12, Matti Aarnio wrote:
>>>> Hi,
>>>>
>>>> I would not worry of it.
>>>> They are not used (that I have seen) in any timing sensitive paths 
>>>> of using the private/secret -key material in signing or encryption.
>>>> (The HexEncoder - and other Encoders - are wrapped in another 
>>>> class, and that another class is referred by usage spots.)
>>>>
>>>> They are used a lot in initializers and constructors, and 
>>>> debugPrint() calls, but not in core loops of e.g. RSA 
>>>> exponentiation engine, EC mathematics, etc.
>>>> If you find table lookups in those parts, there are potential 
>>>> timing side channels to be fixed.
>>>> (How you do a Feistel network (DES, AES) block cipher without table 
>>>> lookups is an interesting question in itself..)
>>>>
>>>> Best Regards,
>>>> Matti Aarnio
>>>>
>>>>
>>>> On 31/03/2022 16.22, Karolin Varner wrote:
>>>>> Morning all!
>>>>>
>>>>> Is the utility functions in HexEncoder supposed to be constant time?
>>>>> They seem to be using a lookup table so the implementations are 
>>>>> not constant time.
>>>>>
>>>>> Best,
>>>>> Karolin
>>>>
>>>>
>>>
>>
>>
>
>


[prev in list] [next in list] [prev in thread] [next in thread]