Názory k článku Mají i dnes smysl otevřené validující resolvery?
-
rsa (neregistrovaný)
OT, ale tohle me zajima
> pro šifrovací algoritmus RSA, který je předchůdcem modernějšího algoritmu ECDSA, na který se postupně přechází.
Jsou elipticke krivky (EC*) povazovany nezavislymi odborniky za bezpecne a lepsi nez RSA? Nedavno jsem to resil u sifrovani VPN...Teorie je, ze vydane a doporucovane hodnoty NIST/NSA mohou mit "vhodne zvolene" parametry, a tim silne omezit teoretickou robustnost EC
-
1. ECC je rodina algoritmů, NIST křivky jsou jen jedny z mnoha, viz např. https://safecurves.cr.yp.to/
2. AFAIK ECC jsou ekvivalentně silné s RSA při výrazně menších velikostech klíčů a podpisů. -
rsa (neregistrovaný)
Diky moc! Tohle je opravdu zajimavy prehled.
> Unfortunately, there is a gap between ECDLP difficulty and ECC security. None of these standards do a good job of ensuring ECC security. There are many attacks that break real-world ECC without solving ECDLP. The core problem is that if you implement the standard curves, chances are you're doing it wrong:
I kdyz z teoretickeho hlediska jsou ECC lepsi, zustanu radsi u sw jeste nejakou dobu "ala debian", implementace RSA jsou overene
Jinak ten standard(?) safe-curves je opravdu uzitecny projekt, jsem prekvapen kolik "officialne" doporucovanych krivek ma nejake slabiny, i jak mohou byt rozlicne!
-
Standard EDDSA pro DNSSEC už máme (RFC 8080). Teď bude ještě potřeba zapracovat na podpoře v crypto knihovnách a následně v DNS serverech.
-
K Ed25519 se objevil zajímavý fakt: Bernstein dlouho tvrdil, že klíče/body na křivce se nemusí validovat (je to napsáno mimochodem i v RFC 8032), ale není to pravda.
U Monero měny se objevila tato zranitelnost: pokud je "key image" bod, který nemá řád křivky (2**252 + 27742317777372353535851937790883648493), je možné udělat double-spend nebo vytváření coinů jen tak: https://getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html
Nikde nebylo zveřejněno, jak přesně exploit funguje, hádali jsme, že bod nízkého řádu umožní jednoduchý bruteforce signatur.
-
Pokud vím, tak ne.
Jediná zmínka je na https://cr.yp.to/ecdh.html o "contributory behavior", kde se píše o testování bodů s malým řádem.
Monero používá mírnou modifikaci EdDSA (hash je Keccak místo SHA2 a seed se nehashuje než se z něho stane privátní klíč). Ale i s původní EdDSA nikomu nic nebrání použít jako veřejný klíč bod s malým řádem a vytvářet k němu podpisy. Nicméně falšování vlastních podpisů není většinou moc užitečné.
V případě Monero tam spíš půjde o to, jak jsou zkonstruované ring signatures.
-
Tak jde o Curve25519, ne o Ed25519. Vše v Monero protokolu je nad Curve25519.
Zranitelnost se týká one-time ring signatures. Problém nevalidních bodů spočívá v tom, že je možné vytvořit vícero "key images" I k stejnému veřejnému klíči P a projde to verifikací. Key image I má zabraňovat double-spendu (něco jako sériové číslo), ověřuje se při přesouvání. Když ale k páru klíčů je možné vytvořit vícero key images, je možný double-spend.
-
hugochavez (neregistrovaný)
@rsa
"...implementace RSA jsou overene..."tak urcite.... :o))))
https://blog.cryptographyengineering.com/2013/09/20/rsa-warns-developers-against-its-own/
https://twitter.com/mattblaze/status/381091674606534656
Dobra volba je ed25519.
PS: doporuceni od AMERICKYHO NISTu ma pro Evropana nulovou hodnotu (spis teda zapornou) a "varovani" soudruhu z NSA ohledne "ECC neni bezpecne" komentoval Moxie Marlinspike slovy "lidem z NSA zda se ujel vlak tak aspon lidi strasi aby nepouzivali crypto se kterym si NSA nevi rady" -
L (neregistrovaný)
AFAIK ECC jsou ekvivalentně silné s RSA při výrazně menších velikostech klíčů a podpisů.
To sa hovori. V skole bolo treba na vysvetlenie a dokaz RSA a znamych utokov 2 hodiny, na ECC asi 30 hodin. Nie je vnimana sila iba dosledok komplexity pre cloveka? Da sa relativna sila ECC voci RSA dokazat? -
Ona se vůbec těžko dokazuje výpočetní náročnost. Doufáme a věříme, že pro RSA ani ECC neexistuje algoritmus pro prolomení v lineárním čase na klasickém (nekvantovém) počítači. Ale kdyby se to někomu povedlo dokázat, dokáže tím zároveň P≠NP.
Taky se čeká, že prolomení RSA ani ECC není NP-complete. Opět, kdyby se to někomu povedlo dokázat, dokáže tím P≠NP. A kdyby to náhodou bylo NP-complete, znamenal by Shorův algoritmus s příchodem kvantových počítačů hrozbu nejen pro dnes převládající asymetrické algoritmy, ale i pro symetrické algoritmy a postkvantové algoritmy – vlastně by zbyly unconditionally secure algoritmy (Vernamova šifra, Shamir Secret Sharing Scheme, …) a vše ostatní by rozluštil kvantový počítač v polynomiálním čase.
A dokázat relativní sílu ECC vůči RSA bude asi ještě vetší oříšek než dokazovat asymptotickou složitost, kde můžete zanedbat některé konstanty…
-
Sten (neregistrovaný)
ECC je slabší při louskání kvantovými počítači a o dost náchylnější na side-channel útok sledováním doby výpočtu (řeší se umělým stanovením minimální doby výpočtu). Na druhou stranu jsou řádově bezpečnější před brute-force útoky, resp. můžete použít výrazně kratší klíče při stejné bezpečnosti.
-
> Na druhou stranu jsou řádově bezpečnější před brute-force útoky, resp. můžete použít výrazně kratší klíče při stejné bezpečnosti.
To jsou dvě různé věci. Brute force proti asymetrickým šifrám nemá moc smysl, tím nerozluštíte ani 512b RSA. Všechny asymetrické šifry, o kterých vím, mají výrazně rychlejší způsob prolomení než bruteforce.
-
Ne, ECC i RSA nejsou post-quantum algoritmy (Lattice-based crypto je jedna z post-quantum computing možností).
Doporučuji shlédnout tuto přednášku od Paula Hoffmana na letošním jarním DNS-OARC meetingu: https://youtu.be/hr_ziislx74?t=5767
-
Podívejte se na tu přednášku... Já myslím, že nemá smysl (u DNS) panikařit s počtem bitů. Pokud chcete něco dlouhodobě šifrovat, tak ano, ale v DNS je to poměrně jedno, protože crypto tady nezaručuje soukromí, ale autenticitu dat ve chvíli její validace, a přínos menších klíčů a podpisů je pro DNS provoz výrazný.
-
Petr M (neregistrovaný)
Šifra je bezpečná, pokud se nedá lousknout v době, kdy je zpráva platná.
Pokud teď dostanu odpověď na DNS dotaz, která platí 1 hodinu a lousknout podpis trvá týden, je to OK.
Pokud teď dostanu podepsanou směnku se splatností 5 let a lousknout podpis trvá rok, je něco hodně blbě.Není třeba být the best v neprolomitelnosti, stačí jenom být good enough a zvolit kompromis mezi prolomitelností, velikostí a výpočetní náročností.
-
Jen drobnost - pozor na replay útok - důležitá je platnost podpisu DNS zprávy, a nikoli její TTL. Resp. aby to nebylo tak jednoduché - důležitá je platnost podpisu aktuálního DNSKEY klíče, kterým je zóna podepsaná.
Po kompromitaci aktuálního klíče bude možné podvrhávat (in-path) dotazy po dobu délky podpisu tohoto klíče, i když dojde k jeho výměně v zóně (nadřazené zóně).
Ale pořád se bavíme o dnech a nikoli o letech, a je mnohem větší šance, že klíče utečou s bývalým zaměstancem a nikoli kvůli masivnímu průlomu v QC.
-
Bez bezpečné i poslední míle je celé DNSSEC úplně k ničemu a tím spíše je k ničemu i otevřený validující resolver. Protože když mi někdo něco podvrhne na trase zařízení-váš_resolver, tak to nepoznám a ještě mne bude hřát pocit falešného bezpečí (!!!). Pokud má mít DNSSEC smysl pro servery, pak jistě, ale byl bych poněkud ujetý admin, který by sice trval na DNSSEC, ale bral si ho z veřejného resolveru (který není pod mou kontrolou).
Čili DNSSEC je dodnes pouze akademická šaškárna (taky ji provozuju), na kterou všichni z vysoka pečou - třeba i Chrome (kvůli existenci TLD s 1024bit RSA klíči). Jo vlastně si mohu do Firefoxu/Chrome dát rozšíření (mám ho, ale jasně jsem zanedbatelná entita). Tedy mi znovu zase vychází, že DNSSEC je dneska stále naprosto nanic.
-
j (neregistrovaný)
https://bugzilla.mozilla.org/show_bug.cgi?id=14328
To stim souvisi, oni soudruzi uz 18 let nejsou schopny implementovat obecnej DNS dotaz ... prej by to byla prace ... a prej by se pak web nacet o 0,000prd ms pozdejs ...
Zato na picoviny, jako zmena UI 10x rocne je casu i prostredku dost ...
Mno tak se aspon implementujou nepouzitelny hovadarny jako trebas hsts ... zejo ...
-
Jednou se připojíte na Wi-Fi někde v kavárně a kdykoli potom dostanu vaši poslední míli přes Pineapple.
Nebo pokud vás zastihnu v té kavárně (byť byste si četl pouze idnes), mohu vám otrávit cache.
Ano, mírně zjednodušuju, ale pro běžné uživatele je to často mission impossible a pro pokročilé je dost oříšek nic nezanedbat. A to nemluvímo takových probémech, jak sehnat bezpečný router.
-
Sten (neregistrovaný)
Můžou třeba jen využívat toho, že u Google je velká pravděpodobnost, že už bude mít celý řetěz vyresolvený v cache, a DNSSEC ověřovat u získané odpovědi; mám to tak na serverech taky (tedy s tím, že to automaticky fallbackuje na rekurzivní resolving). Samozřejmě je spousta ISP, kteří DNSSEC nevalidují. Ale pak je taky spousta ISP, které to dělají, jak se nedávno přesvědčil Wedos.
Pokud jiný zákazník může udělat MITM útok na tvé DNS dotazy uvnitř sítě ISP, je tam o dost větší problém než MITM útok na DNS dotazy.
-
M. (neregistrovaný)
Windows obsahuje DNSSEC aware nevalidujici forwarder=umí se řídit přiznaky ohledně DNSSEC a jak to dopadlo, ale sám nevaliduje. Navíc je v základu vypnut. Je to mířeno spíše pro firemní sítě, kde se bere, že validátor dělá třeba doménový řadič (umí to) a s řadičem se ten koncový forwarder ve woknech baví pomocí doprzněné varianty IPsecu (používá MS soukromou verzi IKE protokolu), jako ochrana toho posledního hopu. Pokud můj domácí router obsahuje validátor a umí třeba IPsec, tak jde ten ve woknech zapnout a trochou oklikou nastavit, aby se ty dotazy obalily klasickým IPsec transportem a bude to OK.
-
j (neregistrovaný)
" Pokud můj domácí router obsahuje validátor a umí třeba IPsec"
Kolik tisicin promile domacich routokrabek umi ipsec? A kolik biliontin procenta z nich ... umi validovat dnssec? (pocet domacich uzivatelu ktery by ak byli schopni to naconfit je exaktne nula)Widle dodneska neumej ani rdnss. Nedelal bych si iluze, ze v pristich 20 letech budou umet validovat dns, natoz ho sifrovat.
Jedina sice naprosto blba ale proste jedina varianta je, ze to bude delat primo aplikace - aspon ty nejrosirenesi a tudiz browsery.
-
M. (neregistrovaný)
Psal jsem, že to je hlavně pro firemní použití, kde to mám svázné doménou a centrálně manažované. On ten DNSSEC podporující resolver, respektive je to zadrátováno v NRPT (Name Resolution Policy Table), tak je zamýšlen hlavně jako komponenta pro DirectAccess.
Nepředpokládám, že by to masy si doma takto přiohýbaly (vyjma pár cvoků). -
Provozovat OVDR muze byt docela narocne z hlediska obrany pred ruznymi utoky. Rad bych upozornil na projekt dnsdist, coz je inteligentni DNS balancer. Dokaze pracovat s obsahem DNS pozadavku, nastavovat ruzne limity poctu dotazu, umi se branit proti pseudorandom subdomain utoku a pod. Je skriptovatelny v LUA. Pisi to lide od PowerDNS. Kdo spravuje nejake vetsi resolvujici DNS, urcite by se na to mel mrknout http://dnsdist.org.
