Přegenerování stávajícího SSH klíče?

[Darkhunter]

Ahoj,
hledal jsem na internetu a divím se, že jsem k tomuto tématu nic nenašel, tak se ptám tady.
Dá se nějak přegenerovat stávající klíč, který je 1024bitový na nový 4096bitový? Jde mi o to, že můj klíč už dávno není bezpečný, ale stále ho používám, protože ho mám na desítkách serverů a to i v AWS, kde přidání nového klíče je ještě složitější.
Ideálně tedy přegenerovat tak, že bude kompatibilní se stávajícími public klíči. Dá se to?
Díky.

[Reklama]

[Mmmartan]

Nedá

[Filip Jirsák]

Nedá se to udělat, veřejný a privátní klíč jsou pevně svázané.
Můžete ale mít na klientovi více klíčů, takže si tam necháte starý i nový a na serverech budete klíče postupně obměňovat za nové.

[modnar]

přegenerovat tak, že bude kompatibilní se stávajícími public klíči

To je snad poruseni bezpecnosti celeho mechanizmu verejneho klice ne? Pouzivas AWS a tohle ti prijde normalni? WTF?

[Filip Jirsák]

přegenerovat tak, že bude kompatibilní se stávajícími public klíči

To je snad poruseni bezpecnosti celeho mechanizmu verejneho klice ne? Pouzivas AWS a tohle ti prijde normalni? WTF?

Porušení bezpečnosti to rozhodně není, protože je to především nemožné.

Když máte 1024bitové číslo, vážně ho nelze nějakým trikem nafouknout, aby z něj najednou bylo to samé číslo, ale 4096bitové (úvodní nuly se samozřejmě nepočítají). Je to, jako kdybyste chtěl: „tady máte pětku, nafoukněte ji do řádu tisíců, ale ať má pořád hodnotu 5 (a je bez úvodních nul)“.

[Reklama]

[snugar_i]

přegenerovat tak, že bude kompatibilní se stávajícími public klíči

To je snad poruseni bezpecnosti celeho mechanizmu verejneho klice ne? Pouzivas AWS a tohle ti prijde normalni? WTF?

Teoreticky by nemuselo, pokud by na to "přegenerování (které neexistuje) byl potřeba private klíč.
Spíš nevím, k čeum by to autorovi bylo - sice by si vygeneroval silnější privátní klíč, ale na public klíč by pořád pasoval i ten původní slabý (protože public klíč neměnil), takže by si vůbec nepomohl...

[k3dAR]

V podstate ano, jen to bude novy/jiny klic ;⁠-⁠)

Proste na stanici vygenerujes novy a pres ssh-copy-id ho posles na servery, nasledne overis ze tim novym se prihlasis a AZ PAK stary ze serveru smazes... Hint: ssh i ssh-copy-id ma volbu -i kterou urcis specifický (privatni) klic soubor

[Karel Karlik]

A nedopadne to třeba tak, že k 4x delšímu private key patří i 4x delší public key - takže ten původní (kratší) public key se bude při pokusu o přihlášení vesele ignorovat, i kdyby nakrásně matematicky pasoval?

[Filip Jirsák]

Tohle je od začátku až do konce nějaké předčasné silvestrovské vlákno, ne?

Velikost klíče v kryptografii slouží jenom k tomu, aby se klíč nedal uhádnout tak, že se bude zkoušet jeden klíč za druhým (případně pokud by byl algoritmus oslaben, spousta klíčů se může přeskočit, ale pořád by šlo o to vyzkoušet nějakou množinu klíčů). Takže i kdyby se používal nějaký algoritmus, který by připouštěl více různě velkých privátních klíčů k jednomu veřejnému klíči, bylo by k ničemu vytvářet nový větší soukromý klíč ke stejnému veřejnému klíči – protože útočník by samozřejmě hádal ten nejmenší možný klíč. (Tohle už stručně napsal snugar_i.)

Asymetrická kryptografie je založená na tom, že existuje dvojice klíčů, soukromý a veřejný, které k sobě patří. Kdyby se použil nějaký algoritmus, který by připouštěl více srovnatelně velkých privátních klíčů k jednomu veřejnému, bylo by velmi obtížné určit jeho bezpečnost. Protože by bylo potřeba vědět, kolik pasujících privátních klíčů je k tomu jednomu veřejnému – protože útočník by se při hádání mohl trefit do kteréhokoli z nich.

[Pavel...]

ehm... chapem, ze otazka je to dost nestastna ... ale ciste teoreticky, co brani doplnit pred cislo v RSA algoritme 3072 nul?

Za predpokladu, ze v tych klucoch nie su metadata, tak algoritmu by mohlo byt jedno, ze dostal cislo s kopou nul na zaciatku .

[k3dAR]

spis to chce polozit otazku, "@Darkhunter PROC pozadujes (nesmyslne) zachovani public klice" ? pises o komplikacich s AWS, pokud jde o EC2 tak tam se to snad chova jako beznej linux server, kde je bezne/normalni/jednoduche reseni co sem psal...

nebo snad prijdes do zamecnictvi s pozadavkem "Muzete vy udelat kopii tohoto klice, ale pridat lepsi zabezpeceni ale tak aby byl kompatibilni se stavajici vlozkou ktereou se mi nechce menit" ? ;-)

[Karel Karlik]

ehm... chapem, ze otazka je to dost nestastna ... ale ciste teoreticky, co brani doplnit pred cislo v RSA algoritme 3072 nul?

Za predpokladu, ze v tych klucoch nie su metadata, tak algoritmu by mohlo byt jedno, ze dostal cislo s kopou nul na zaciatku .

A nevyzaduje nahodou RSA aby nejvyssi bit modulu byl 1? (a delka modulu je prave bitova sila RSA - cili to je to misto kde se rika 1024 nebo 4096 bitu)
Samotny privatni klic je pak d=reseni nejake rovnice ktera zalezi na cisle e ktere je soucast verejneho klice (a muze zustat stejne) a totientu modulu, takze obecne nemuze zustat stejne (nesmi se pritom zapomenout ze modulus se ma generovat jako soucin dvou velkych prvocisel). Je velmi nepravdepodobne ze by platilo d*e = 1 mod l1024 a zaroven d*e = 1 mod l4096 pro dve ruzna cisla l1024 a l4096
(teda co ctu, tak nekdo za klic povazuje jenom d, a nekdo k tomu prihazuje i ty dve prvocisla ze kterych se pocita modul - pak uz je uplne mimo misu uvazovat o tom ze by se vychazelo z predem urcene hodnoty klice, protoze k tomu klici by nejenom ze bylo potreba dopocitat modul, ale musel by vyjit jako soucin dvou znamych prvocisel ... coz si myslim bude jeste obtiznejsi problem nez jenom obycejna faktorizace)

Beda implementaci ktera si nezkontroluje ze predhozene klice splnuji zakladni predpoklady.


A k tomu plus vsechny pripominky ostatnich na to, ze takovy ohejbak se delat nema. Jestli AWS chce 4096bit rsa, tak ozulit to realne 1024bitovym nenaplnuje smysl pozadavku.

[Pavel...]

A nevyzaduje nahodou RSA aby nejvyssi bit modulu byl 1?

prislo by mi to logicke, ale nevsimol som si nikde taku poziadavku pri pouzivani klucov (co sa deje pri generovani nas trapit nemusi)

Druha vec je, ze pokial dobre chapem, tak po vypocitani predmetneho sucinu prvocisiel uz nasledne nik neriesi, ci to vazne je sucin prvocisiel. (ono praticky si ani neviem predstavit ako by to niekto skusal riesit)

Takze navrh na tool c2, co by splnil zabavnu poziadavku z uvodu:

Majme:
l1024 = p*q
d*e = 1 mod l1024
Pricom p a q nepozname.

Doba pokrocila, takze l1024 uz vieme hrubou silou rozdelit na p a q.
Dalej je uz postup trivalny

l4096 = p^4 * q^4
e2 = dopocitame vyjadrenim (e*d*n-1)^4=(p*q)^4 do tvaru e2*d*n2-1=(p*q)^4
d2 = d

Z predpokladu, ze v dvojici suborov s klucmi je l1024 iba raz, mozme zamenit ten subor ktory ho obsahuje, druhy mozme ponechat a
bude nas hriat pri srdci, ako sme oklamali system

[Karel Karlik]

prislo by mi to logicke, ale nevsimol som si nikde taku poziadavku pri pouzivani klucov (co sa deje pri generovani nas trapit nemusi)

To je jedna z tech veci kde rikam ze "beda implementaci ktera si to nezkontroluje"
Jestli AWS vyzaduje 4096 bit a nejak to overuje (a kdyby ne tak by asi tenhle thread neexistuje), tak je otazka jestli overuje jenom ze pole "delka modulu v bajtech" ma hodnotu 512, nebo i ze ten modul ma nejvyssi bit nastaveny na 1.

Druha vec je, ze pokial dobre chapem, tak po vypocitani predmetneho sucinu prvocisiel uz nasledne nik neriesi, ci to vazne je sucin prvocisiel. (ono praticky si ani neviem predstavit ako by to niekto skusal riesit)

To uz se taky validuje hur, pokud se jako soucast toho privatniho klice nepredavaji i ty prvocisla (coz se nekdy dela) - pak je staci vynasobit. Opet je to na ssh klientu.

Takze navrh na tool c2, co by splnil zabavnu poziadavku z uvodu:

p,q klidne znat muzeme, kdyz mame privatni klic.

Jeste si tady projitotu opisu co ma byt ve kterem klici (v tom jsem mel trochu maglajz):
public key: n (modul), e
private key: d (to je to co nam resi d*e=1 mod l)
muze se zahodit: p, q, l

-> tj n a e NEmime menit, jinak nesplnime pozadavek ze nam to ma pasovat na existujici public key
a jsme trochu v loji protoze delka klice je zapecena do public key


A teda v opacnem smeru by to znamenalo zachovat puvodni privatni klic (nesmime menit d) distribuovany nekam (na aws? aby se z nej dalo prihlasovat nekam dal?), a to pak teda nevim jak jinde menit public key na 4096 bit aby pasoval.


Pak pro vypocty trochu pozor, l neni p*q
n = p*q
l = euleruv totient N (coz se teda pro soucin dvou prvocisel rovna (p-1)*(q-1)), nebo moderneji carmichaeluv totient N (coz vychazi jako nejmensi spolecny nasobek p-1 a q-1)

pri generovani puvodniho klice jsme meli urcene e a prave dopocitane l1024 a z d*e=1 mod l1024 se urcilo e
takze kdyz mame d2 nebo e2 (a k nim l4096), tak se uplne stejnym postupem dopocita to druhe d2*e2=1 mod l4096

A kdyz dopocitate e2 tak se vam jeste muze stat ze implementace vas poslou do pryc protoze vyslo prilis velke e (normalni hodnota je pry opravdu jenom 3 bajty)


Celkove mi to prijde jako nesmyslna divocina.

[Džan]

Tohle je dost špatný přístup z hlediska bezpečnosti, výměna SSH klíče není nic složitého, spíš by to mělo být naprosto běžnou záležitostí (koupím nový notebook, generuji novou sadu klíčů).
Klíče, které přistupují k důležité infrastruktuře pak mít ideálně uložené na hardwarovém klíči - Yubikey atd.
Navíc, jestli jsi ten 1024-bitový klíč generoval v době kdy tenhle keylength byl v módě, je taky dost pravděpodobné, že už někam utekl.