Dotaz: SSH klíč - RSA, nebo ED25519?

[Petr Fiedler]

Který typ klíče je podle vás bezpečnější, RSA, nebo ED25519? Četl jsem o tom něco, ale nevyznám se v tom a nedokážu posoudit, zda je to pravda.

Odpovědi

[k3dAR]

nevim jiste co je bezpecnejsi, ale pouzivam RSA 4096b (s tim ze vychozi(v ssh-keygen) pro RSA je 2048 a oznacene jako "povazovane za dostatecne")...

ssh-keygen -t rsa -b 4096

[Filip Jirsák]

Z hlediska kryptografické bezpečnosti jsou pro použití s SSH stejné. RSA jsou (v implementaci v reálných produktech) mnohem starší, takže takový klíč bude podporován všude (kdybyste se chtěl připojovat třeba z nějakého mobilu nebo nějakého jednoúčelového zařízení). Klíče pro eliptické křivky jsou zase menší. Pokud se takhle ptáte, volil bych sázku na jistotu a tedy RSA.

[alkoholik]

U starych implementaci SSH se ale nediv, ze umi treba jenom 1kb RSA klic.
Se silnymi klici je RSA pomalejsi.

[alkoholik]

A jsem si skoro jisty, ze s ED25519 dostanes automaticky i PFS. U RSA zalezi na okolnostech.

[Petr Fiedler]

Díky oběma za odpověď.
Já jsem právě četl tento článek a autor v něm zmiňuje, že lepší je ten ED25519, ale nedokázal jsem posoudit, jestli tomu tak skutečně je, nebo ne.

[pavele]

ED25519 není dostatečně prověřen časem.

[Semo]

ED25519 je pravedpodobne lepsi, ale RSA je vyrazne kompatibilnejsi. Ak zijes len medzi svojimi Linuxami, tak kludne ED25519. Ak potrebujes dostupnost (z) kadekde inde, tak RSA.

[Petr Fiedler]

Díky všem.
Pokusím se reagovat s ohledem na odpovědi všech.

Takže, -t rsa je léty prověřen, je mnohem více kompatibilní a s parametrem -b 4096 by tento typ měl být bezpečný.
Nemusí ale vždy zahrnovat PFS.

Oproti tomu -t ed25519 není léty prověřený a nemusí být vždy kompatibilní. Je ale rychlejší a dle tohoto článku je nejlepším typem ssh klíče. Navíc by u něj měly jít nastavit parametry -o (vyšší odolnost proti brute-force password cracking) a -a (KDF - key derivation function). Což jsou podle mě super vlastnosti.

1) Chápu správně, že ty dva výše zmíněné parametry lze nastavit pouze u ED25519, nebo to lze i u RSA?

2) Spojení budu navazovat mezi mým pc (LM 19), mým nb (LM 19) a mobilem (Samsung GALAXY S8+, Android 8.0 - do konce března přijde 9ka, app JuiceSSH). Toť vše. A chci být dobře chráněn proti útokům. Mě se tedy lépe jeví, pokud to tedy bude kompatibilní, použít ED25519. Co říkáte?

Co se týče PFS, tak dle tohoto článku stačí použít další 2 klíče a PFS by mělo být zajištěno. Pokud to tedy správně chápu (překládám strojově). Otázka je, jestli to (další 2 klíče) lze použít vždy? I s RSA, i s ED25519 a kdykoliv při běžných podmínkách?

[Filip Jirsák]

Chápu správně, že ty dva výše zmíněné parametry lze nastavit pouze u ED25519, nebo to lze i u RSA?

Lze to i u RSA. Ty „super vlastnosti“ jsou prakticky k ničemu, vymaže je pronájem botnetu nebo cloudu. Dneska je to sice módní, zpomalovat funkce pro ověření hesla, ale pak dotyčný pořídí cluster pro ověřování hesel, aby to bylo rychlejší… Pokud chcete odolnost proti útoku hrubou silou, musíte používat dostatečně silné heslo. Pomalé funkce nejsou nic jiného, než snaha to ošidit a používat slabší hesla – a to se jednou vymstí. Když k heslu přidáte jenom dva znaky z malých a velkých písmen a číslic, ztížíte útočníkovi louskání hesla víc, než kdybyste tu funkci zpomalil tisíckrát.

A chci být dobře chráněn proti útokům. Mě se tedy lépe jeví, pokud to tedy bude kompatibilní, použít ED25519.

Z hlediska odolnosti proti útokům je úplně jedno, kterou z těch dvou variant zvolíte – je potřeba jen mít dostatečně dlouhý klíč. A pokud chcete být chráněn v případě úniku souboru s privátním klíčem, je potřeba mít dostatečně silné heslo. Doporučil bych mít dva klíče, na každém zařízení jeden – pokud pak třeba ztratíte mobil, stačí na serveru rychle zneplatnit klíč a nemusíte řešit to, že musíte nejprve i pro notebook vygenerovat nový klíč.

Jinak dobrá ochrana proti útokům závisí na spoustě jiných věcí, typ klíče je nepodstatný detail. Důležité je povolit jen přihlašování klíčem a mít aktuální software.

Nevím, proč tak řešíte PFS – to tím spojením budete přenášet nějaká tajná data, která by měla pro někoho význam, kdyby se k nim dostal za několik měsíců nebo let?

[Petr Fiedler]

Lze to i u RSA. Ty „super vlastnosti“ jsou prakticky k ničemu, vymaže je pronájem botnetu nebo cloudu.

To nechápu, jak to myslíš?

Nevím, proč tak řešíte PFS – to tím spojením budete přenášet nějaká tajná data, která by měla pro někoho význam, kdyby se k nim dostal za několik měsíců nebo let?

Co já vím, co tím spojením budu v budoucnu přenáše? Ale je možné, že např. dokumenty s osobními údaji.

[Filip Jirsák]

Lze to i u RSA. Ty „super vlastnosti“ jsou prakticky k ničemu, vymaže je pronájem botnetu nebo cloudu.

To nechápu, jak to myslíš?

Ty vlastnosti slouží k tomu, aby zpomalili útočníka, když získá zaheslovaný privátní klíč a bude zkoušet rozlousknout heslo. Když toho útočníka zpomalíte 1000×, útočník na to zareaguje tak, že to louskání spustí na botnetu nebo cloudu s 1000 stroji, a je zase na svém původním čase. Nebo dneska se na tyhle paralelní výpočty používají GPU. Mimochodem, když heslo prodloužíte o dva znaky z abecedy obsahující malá a velká písmena, číslice a deset symbolů, zpomalíte útočníka 5000×. Tyhle pomalé funkce se používají tam, kde nechcete nutit uživatele, aby nezadávali slabá hesla – provozovatel se pak snaží nízkou entropii nahradit tímhle trikem. Když ale máte pod kontrolou to, jak dlouhé bude heslo, nespoléhal bych na tyhle triky a prostě bych použil dostatečně silné heslo. Navíc tyhle pomalé funkce často nejsou navržené a už vůbec ne kontrolované kryptology, ale nadšenými amatéry. Ti sice většinou staví na osvědčených kryptografických algoritmech, ale je otázka, zda dodržují všechny předpoklady. Většina útoků na kryptografii není vedena proti matematickému algoritmu, ale proti jeho implementaci a různým postranním kanálům. Resp. pokud už je útok veden proti samotnému algoritmu, bývá to v době, kdy už se o něm tuší, že je slabý a je na ústupu. Hashovací funkce (nebo funkce pro odvození klíče) by teoreticky měly být bezpečné pro jakýkoli vstup, ale zatím nebyla vymyšlena žádná dokonalá hashovací funkce, vždy se nakonec našly nějaké slabiny – a opakování ty slabiny klidně může násobit.

Co já vím, co tím spojením budu v budoucnu přenáše? Ale je možné, že např. dokumenty s osobními údaji.

OK. Já jsem si pod SSH automaticky představil správu serveru. Ale máte pravdu, že s PFS je to bezpečnější – i kdybyste to teď používal jenom pro administraci, klidně přes to někdy v budoucnosti můžete chtít poslat něco citlivého a nejspíš byste si pak jen řekl „je to bezpečné, vždyť je to SSH“ a už byste si nevzpomněl, že tam vlastně nemáte PFS.

[Petr Fiedler]

Díky moc Filipe :)

[alkoholik]

2 klice navic se pouzivaly u SSH protokolu v1, ktery neni povazovany za bezpecny a uz se nepouziva.
U v2 musis vynutit CipherSuite s diffie-hellman vymenou klicu (DH, ECDH).

[Petr Fiedler]

Díky za nasměrování.