Názory k článku Bernsteinovy eliptické křivky
-
Karel (neregistrovaný)
Možná je to jen důsledek moderní doby. Dnes je vše černobílé, každý musí mít na všechno názor. A to radikální.
Vše je buď úžasné, nebo příšerné. Vše musíte buď milovat nebo nenávidět. Ostatně, tak to být musí, ne? Vždyť na facebooku máme jan palec nahoru a palec dolů. Nic mezi.
V takové době se není co divit, že řada spoluobčanů se snaží akorát odhadnout, jestli jste klikl na palec nahoru, nebo na palec dolů. Možnost, že byste neklikl, je nemyslitelná. A tomu pak odpovídá povaha otázek.
-
Ondrej Mikle (neregistrovaný)
Zhruba to chápete správně.
Těch křivkových parametrů je ale vícero - prvočíslo pro konečné těleso, tvar křivky (určuje přípustné algoritmy), koeficienty pro křivku ve Weierstrassově tvaru y2 = x3 + Ax2 + x
Koeficient A se například ladil taky kvůli "twist security" zmiňované v článku.
U NIST křivek se například jako jedno z prvočísel použilo 2256 − 2224 + 2192 + 296 − 1, protože v jejich implementaci se jim taky s tím dobře počítalo. Je celkem dobře vidět, že nastavené bity se vybírali velmi specificky.
ECC má proti RSA jednu zásadní nevýhodu: křivek je mnoho a každá má mnoho speciálních případů.
-
Ondrej Mikle (neregistrovaný)
Oprava - myslel jsem křivku Montgomenryho tvaru, Weierstrassov tvar je obecný (jak jsem říkal, mnoho speciálních případů).
-
MilanK (neregistrovaný)
Děkuji za článek, vůbec jsem netušil, že jsou v těch různých eliptických křivkách takové "implementační" rozdíly.
V článku vyzvihujete rychlost, ale chybí (aspoň základní) srovnání s jinými algoritmy, to jsem našel na na http://bench.cr.yp.to/.
Nedávno jsem testoval algoritmy eliptických křivek pro IPsec na ARM, ale zůstal jsem u DH/RSA: ECDH je mnohem rychlejší než původní DH, ale operace podpis + ověření trvaly pro NIST křivky stejně dlouho, jako RSA (EC podpis i EC ověření trvaly zhruba polovinu času potřebného pro RSA podpis, RSA ověření je při rozumně zvoleném exponentu zanedbatelné -- t + t = 2t + 0). Po přečtení tohoto článku ještě EC zvážím, ale s jinými křivkami.
-
Ondřej CaletkaZlatý podporovatelKdysi jsem si seriálu o SSH postěžoval, že pro klíče typu ECDSA, které OpenSSH preferuje, neexistuje podpora pro SSHFP záznamy. Toho se v den vydání chytil Ondřej Surý a téměř rok poté vyšlo i RFC 6594. Že dodnes není implementace ve vanilkovém SSH konformní s tímto RFC, přestože patche existují, to mě štve. Ale ještě víc mě naštvalo, když loni na podzim vyšlo OpenSSH 6.5 s podporou Ed25519 klíčů, přitom bez podpory SSHFP záznamů. A standard na sebe nechává čekat. The history book on the shelf, keeps always repeating itself… :(
-
ten dns zaznam je ovsem principalne spatne navrzeny uz id sveho vzniku.
kdyby to ondrej vzal za spravny konec, tak tu mame sshfp verze 2 a sshfp by bylo na ceste stat se osolete.spravce mapovani by mel byt iana.
do mapy cisel by mely patrit v implementaci mandatorni algoritmy
mimo cisla by melo byt mozne poslat jeste standardizovany string opet spravovany iana popisujici volitelne implementace
melo by jit poslat nestandartni string oem/experimentalni implementace -
Ondrej Mikle (neregistrovaný)
Aha, o rozporu mezi Ed25519 a chybějící podporou pro odpovídající SSHFP jsem nevěděl.
Pamatuju si, že v TLS WG se dost bojovalo i o takovou drobnost, že Curve25519 má od první implementace wire-format souřadnic little-endian a to se nelíbilo lidem, co chtějí mít všechno v network order (big-endian).
Nakonec se to protáhlo na snahu standardizovat "formát na drátě" všech ECC.
Jen jako poznámka: NIST křivky mají standardizovaný wire-format s prvním bajtem určující jak je bod zapsán, pak data bodu:
- 00 - bod v nekonečnu
- 04 xx yy zz ... - bod v nekomprimovaném formátu (x a y souřadnice)
- 02 xx yy zz .... - bod v komprimovaném formátu, jen x souřadnice, kladné znaménko
- 03 xx yy zz .... - bod v komprimovaném formátu, jen x souřadnice, záporné znaménko
Křivka Curve25519 je definována, aby nemusela používat znaménko (DH funkce ve větě 2.1 v původním paperu, link je v sekci "Na co je která křivka dobrá"). Bod v nekonečnu je validní bod na křivce, ale pro DH se nepoužívá.
-
Karel (neregistrovaný)
Pokud by Nist byl člověk, tak by to bylo divné. Ale tohle je NIST. Nejen že to je zkratka, ale ani nemá nic společného s křivkou. Volně a rozsáhle přeloženo je to "křivka, tak jak ji navrhl National Institute of Standards and Technology"
A tam už se to běžně používá i v opačném pořadí. HD rozlišení, DVD kvalita, USB kabel, ISO norma.
-
Ondrej Mikle (neregistrovaný)
Celá kryptografie je téměř samá výjimka :-) Existuje směr "provable security", ale ten používá často předpoklady, které nemohou v našem světě existovat (a to by bolo na velmi dlouho).
> Ale co ostatne utoky?
Jako ty co neznáme a tudíž se jim těžko lze bránit? Od toho je rigidní návrh založen na spoustě předchozího výzkumu.
Mimochodem, většina útoků na ECC je spíš na implementace (cachování, časové postranní kanály), těch algebraických moc není - až na ty zmíněný proti "křivkám s malou charakteristikou".
-
Ondrej Mikle (neregistrovaný)
Díky za pochvalu, ale na ne-programovacím jazyce se prostě nelze shodnout:
Článek byl napsán v češtině, korekturu dělali alespoň 4 rodilí čeští mluvčí včetně redakce (o kterých vím).
Z článku byly odstraněny násilné překlady jako "biraconiálně ekvivalentní", kde ekvivalent neexistuje. Například s touhle větou nelze hnout ani s velkou překladatelskou gymnastikou:
"Our recommended curve for EdDSA is a twisted Edwards curve birationally equivalent to the curve Curve25519 [...]"
Existuje jediný způsob, jak výrazy budou znít "nativně": prostě je používat. Před 20+ lety se lidi taky smáli překladu "hovorca <-> mluvčí".
(Osobně bych všechno kromě angličtiny, latiny a možná mandarínšké čínštiny zrušil, ale spousta lidí bůhvíproč nesouhlasí.)
