[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <87poz62ihf.fsf%l.stelmach@samsung.com>
Date: Thu, 19 Nov 2015 15:04:28 +0100
From: Łukasz Stelmach <l.stelmach@...sung.com>
To: Ismail Kizir <ikizir@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: A new, fast and "unbreakable" encryption algorithm
It was <2015-11-19 czw 13:31>, when Ismail Kizir wrote:
> On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmach <l.stelmach@...sung.com> wrote:
>> It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote:
>>> Hello,
>>>
>>> I've developed a new encryption algorithm, which dynamically changes
>>> the key according to plaintext and practically impossible to break.
>> [...]
>>> I will be glad to see my algorithm included in Linux distributions.
>>> Please feel free to ask if you have any questions.
>>
>> How resistant to side-channel attacts is or can be an implementation of
>> your algorithm? Not being an expert I am a bit worried about this
>> particular line
>>
>> XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1)));
>>
>> which if I understand it correctly makes a memory access depending on
>> secret data. Because memory accesses are note constant time operations
>> due to cache one might try (and succeed?) learning about secrets by
>> measuring time required to encrypt or decrypt data.
>
> I am not an expert and never claimed it. And I accept it's vulnerable
> to side channel attacks like the one you mentioned. With this
> occasion, I want to emphasize one point: I don't claim that the my
> algorithm is perfect. But, take a look at this:
>
> But, I am sure, this "dynamic key model" is the right way to follow
> for the encyption.
The issue I am attempting to point out is that even if mathematically an
algoritm is perfectly unbreakable (there is no easier way to recover
plaintext than a brute force attack) and its implementations are/can be
fast (in terms of clock cycles per encrypted byte) it may be of no
practical use because of possible side-channel attacks (the more
pracrical an attack the less usefull an algorithm/implementation).
Sometimes side-channel vulnerabilities can be fixed in software but they
need to be well understood.
IMHO if you want to "sell" your algorithm you need analyse its possible
side-channel weaknesses too. Moreover, if you'd like your algorithm to
become a part of Linux kernel I recomend you prepare a patch plugging it
properly into crypto/ directory.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
Download attachment "signature.asc" of type "application/pgp-signature" (473 bytes)
Powered by blists - more mailing lists