Systém asymetrické kryptografie NTRU je dostupný pod open source licencí (diskuse)

[Boris Nikitinskij]

asi zacnem implementovat do TC a Lin. jadra... Ked bude cas cez Vianoce. Alebo sa uz niekto do toho pustil? Aby som nerobil to co uz niekto robi :D

[Luk]

Co se týká jádra, zatím o tom v LKML není ani slovo, takže velmi pravděpodobně to nikdo ani nenavrhl, natož aby to implementoval.

[Jendа]

Jako lama se zeptám: k čemu je v TC nebo v kernelu asymetrická kryptografie? U kernelu mě napadá jen podepisování modulů a u TC vůbec nic.

[xm]

Zrovna na podepisování není NTRU vhodné NTRUSign je totiž broken:

NTRUSign is not a zero-knowledge signature scheme and a transcript of signatures leaks information about the private key, as first observed by Gentry and Szydlo.[1] Nguyen and Regev demonstrated in 2006 that for the original unperturbed NTRUSign parameter sets an attacker can recover the private key with as few as 400 signatures.[2]

[Luk]

AFAIK bývala v kernelu podpora RSA kvůli multicastu IPSec. Jestli ještě je, to nevím. A také nevím, do jaké míry se to reálně používá.

[Michal Kubeček]

To se mi moc nezdá, v gitu jsem nenašel žádné stopy jaderné implementaci RSA až do roku 2011, kdy se na tom začalo pracovat kvůlli UEFI "Secure Boot". A dřív asi také ne, spíš se o tom jen uvažovalo - aspoň podle tohoto dokumentu (z roku 2003). Naopak, myslím, že si vzpomínám, že Linus se dost zřetelně vyjadřoval v tom smyslu, že asymetrické algoritmy do jádra nepatří.

[Luk]

Je to možné. Možná si to pamatuji špatně a šlo opravdu jen o plán to tam dát.

[WNJ]

Muze poskytovat sifrovaci rozhrani aplikacim, misto aby to delala knihovna. Je praktictejsi to mit na jednom miste, kde se da dobre postarat o optimalziaci na architekturu a podobne.

[Luk]

Na druhou stranu má každé volání jádra ohromnou režii. Volání funkce z knihovny znamená několik málo instrukcí, kdežto volání jádra se pohybuje někde o dva řády výše. K dalším nevýhodám implementace v jádře patří například spotřeba fyzické paměti nebo rozsáhlé dopady případných chyb v implementaci (mohou destabilizovat celý systém). Nemá cenu dávat do jádra něco, co tam být nemusí.

[Michal Kubeček]

CryptoAPI není a nikdy nebylo zamýšleno jako rozhraní pro aplikace. Možná by se k tomu nějakým trikem zneužít dalo, ale bylo by to zoufale neefektivní. Od toho, aby to bylo "na jednom místě", jsou dynamické knihovny.

[Ivan]

Nojo, co kdyz ale mam nejakou kartu hardrwarove akceleruje nejaky sifrovaci algoritmus? At uz symetricky anebo aymetricky. Treba takove OpenSSL se da prelozit s podporou Hw akcelerace.

[Michal Kubeček]

To je ale něco úplně jiného než CryptoAPI nebo jakákolik jiná implementace RSA v jádře.

[egg]

Je praktictejsi to mit na jednom miste, kde se da dobre postarat o optimalziaci na architekturu a podobne.

Takže nejpraktičtější by bylo vrazit do jádra všechny užitečné knihovny, ne? Něco mi na tvé argumentaci nesedí.

[pasky]

V posledních pár dnech bylo NTRU implementováno do strongSwanu, právě jsem si to úspěšně s latest gitem nasetupoval (větev ntru).

[Petr Tomášek]

NTRU is a patented public-key cryptosystem...

[Luk]

Tohle je samozřejmě komplikace toho typu, jakou známe například z FreeType. Tady softwarové patenty neplatí, nic nebrání v implementaci a používání. Problém to ale může být v USA a dalších státech, kde patenty platí, takže se to nemusí dostat ani do vanilly, natož do některých distribucí.

[marbu]

Ani když je vlastník těch patentů dá k dispozici? Viz:

NTRU cryptographic patents may be used as long as the user adheres to version two (2) of the GPL License. For details please refer to COPYING-2.txt included in this distribution.

[Luk]

V tom případě by s tím pravděpodobně problém nebyl (vzhledem k tomu, že se pro jádro používá právě GPLv2).

[Foo Bar]

A co v případě, že bude potřeba algoritmus opravit, a opravu už vlastník patentu nedá volně k dispozici?

Jen se podívejte, kolik patentů je okolo ECC, a jaký je v tom nepořádek: ECC patents

[Luk]

V tom případě to bude komplikace. Ta oprava by samozřejmě znamenala nový patent, který by skutečně nemusel být poskytnut.

Jediné "konečné řešení" by bylo zrušení SW patentů tam, kde platí, v první řadě v USA. Ovšem i když tam před 2 lety proběhla velká reforma patentového práva, SW patenty zůstávají.

[Foo Bar]

Jediné "konečné řešení" by bylo zrušení SW patentů tam, kde platí, v první řadě v USA. Ovšem i když tam před 2 lety proběhla velká reforma patentového práva, SW patenty zůstávají.

Naprosto s Vámi souhlasím, a proto mne NTRU nechává velmi chladným. Hrozba toho, že firmu držící patenty na NTRU koupí nějaký velký patentových moloch/troll přesně ve chvíli, kdy se algoritmus začne mohutně používat, je mnohem reálnější než radikální pokrok na poli kvantových počítačů.

Pokud máme na poli asymetrické kryptografie někam poskočit, tak bych byl raději za nějaký royalty-free algoritmus, než aby se opakovala situace s ECC.

[Foo Bar]

(IANACryptographer) Nejsem si jistý, zda-li je všeobecné juchání na místě. NTRU je příliš nový algoritmus na to, aby byl dostatečně prověřený.

Útoky na NTRUEncrypt se dají najít i mimo Wikipedii, ale trochu mne děsí ten autoritativní styl, kterým je psaná stránka:

https://en.wikipedia.org/wiki/NTRUEncrypt#Attacks

Using the latest suggested parameters (see below) the NTRUEncrypt public key cryptosystem is secure to most attacks.

A odkaz je na stránky autorů algoritmu :).

Další odkazy:

http://andrewl.dreamhosters.com/archive/64529101.pdf (Coppersmith & Shamir, 1997)

http://www.mathnet.or.kr/mathnet/kms_tex/982882.pdf (Han, 2005)

Takže nevím, jestli je všeobecné veselí a implementace do kernelu zatím na místě. Ale třeba jsem jenom skeptik, ale tohle je na mě příliš moc zaštítěné komercí.

[d.c.]

Ja tu politiku v posledni dobe prilis nesleduji, ale "nestoji" za tim ten stejny (patrne neexistujici, nebot az prilis tajemny) clovek, co stal kdysi za superhyperbezpecnym sifrovanim disku, o kterem se tez nedalo takrka nic zjistit? (no flame, just asking)