Kan ik een openbare sleutel krijgen van een privésleutel van RSA?

Kan ik een openbare sleutel krijgen?

Het is gemakkelijk om openssl rsa te gebruiken:

$ openssl rsa -in the-private-key-from-your-question.pem -pubout writing RSA key -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtrKVnwse4anfX+JzM7imShXZU C+QBXQ11A5bOWwHFkXc4nTfEOr3fJjnRSU5A3IROFU/pVVNiXJNkl7qQZK5mYb8j 3NgqX8zZJG7IwLJ/Pm2sRW5Qj32C/uJum64Q/iEIsCg/mJjDLh1lylEMEuzKgTdW toeLfxDBL2AJ20qXzQIDAQAB -----END PUBLIC KEY--- 

Als je een idee wilt krijgen van wat er in een sleutelbestand zit, kun je de -text optie doorgeven om een door mensen leesbare (soort van) debug-dump te zien. Op deze manier kun je zorg ervoor dat een sleutelbestand zowel privé-informatie als de openbare informatie bevat. Vooral het bevat de modulus en publicExponent die de openbare sleutel volledig beschrijven:

$ openssl rsa -text -in the-private-key-from-your-question.pem Private-Key: (1024 bit) modulus: 00:ad:ac:a5:67:c2:c7:b8:6a:77:d7:f8:9c:cc:ee: 29:92:85:76:54:0b:e4:01:5d:0d:75:03:96:ce:5b: 01:c5:91:77:38:9d:37:c4:3a:bd:df:26:39:d1:49: 4e:40:dc:84:4e:15:4f:e9:55:53:62:5c:93:64:97: ba:90:64:ae:66:61:bf:23:dc:d8:2a:5f:cc:d9:24: 6e:c8:c0:b2:7f:3e:6d:ac:45:6e:50:8f:7d:82:fe: e2:6e:9b:ae:10:fe:21:08:b0:28:3f:98:98:c3:2e: 1d:65:ca:51:0c:12:ec:ca:81:37:56:b6:87:8b:7f: 10:c1:2f:60:09:db:4a:97:cd publicExponent: 65537 (0x10001) privateExponent: (…) 

Reacties

• @Pysis: dit antwoord gaat niet over ” het vinden van ” het publiek via de publieke sleutel. Het is eenvoudig dat alle informatie die nodig is voor zowel het privé- als het openbare gedeelte wordt opgeslagen in het privésleutelbestand. In plaats daarvan ontbreekt alle informatie met betrekking tot het privégedeelte in het bestand met de openbare sleutel.
• @Pysis Dit is asymmetrische codering.
• @Pysis Ja, asymmetrische codering is ” enigszins asymmetrisch “.
• @SteffenUllrich Die zin zou deel moeten uitmaken van je antwoord
• @Mehrdad: in de context van echte informatiebeveiliging wordt alles wat praktisch onhaalbaar is, als onhaalbaar beschouwd. Informatietheoretische beveiliging is hier irrelevant omdat het uitgaat van een onbeperkte rekenkracht die simpelweg niet bestaat. Dus alle informatie over het privégedeelte ontbreekt moet worden gelezen als alle informatie die het in de praktijk mogelijk maakt om de privésleutel af te leiden, ontbreekt .

In de praktijk, ja, u kunt haal de openbare sleutel uit de privésleutel. In principe zou het mogelijk zijn om een privé RSA-sleutel te maken waarvan de overeenkomstige openbare sleutel niet gemakkelijk kan worden gemaakt verkregen, maar hiervoor is het gebruik van zowel een niet-standaard methode voor het genereren van sleutels als een niet-standaard opslagformaat voor persoonlijke sleutels nodig.

Laten we snel de basis bekijken. Een openbare RSA-sleutel bestaat uit twee waarden:

• de modulus n (een product van twee stiekem gekozen grote priemgetallen p en q ), en
• de publieke exponent e (die hetzelfde kan zijn voor veel sleutels en meestal wordt gekozen als een klein oneven priemgetal, meestal 3 of 2 ¹⁶ +1 = 6 5537).

Ondertussen vereist een RSA-privésleutel minimaal de volgende twee waarden:

• de modulus n (hetzelfde als in de publieke sleutel), en
• de private exponent d (berekend op basis van de publieke exponent e en de factoren p en q van de modulus).

De meeste formaten voor het opslaan van privé RSA-sleutels, inclusief de PKCS1 RSAPrivateKey-indeling die in uw vraag wordt weergegeven, slaat eigenlijk ook een aantal extra waarden op, waaronder:

• de openbare exponent e ,
• de factoren p en q van de modulus,
• de verminderde privé-exponenten d _p = d mod ( p − 1) en d_q = d mod ( q − 1), en
• de ” CRT-coëfficiënt “ q _inv = q ^{− 1} mod p .

In het bijzonder de opname van de publieke exponent e in het formaat van de privésleutel betekent dat de openbare sleutel triviaal kan worden geëxtraheerd uit een PKCS1-compatibel privésleutelbestand.Zelfs als de openbare exponent e niet was opgenomen in het privésleutelbestand, is het mogelijk om de factoren p en q van de modulus te kennen, beide exponenten gemakkelijk te berekenen op basis van de andere. En tot slot, zelfs als we de factoren van de modulus niet kenden, konden we voor op de gebruikelijke manier gegenereerde RSA-sleutels eenvoudig de meest gebruikte waarden van e testen en kijken welke van hen genereert cijferteksten die correct kunnen worden gedecodeerd met de opgegeven privésleutel.

Dat gezegd hebbende, als we een niet-standaard RSA-sleutelgeneratie-algoritme zouden gebruiken dat e ( of d ) willekeurig uit het toegestane bereik van waarden (dwz de gehele getallen groter dan 1 en kleiner dan en coprime met λ ( n ) = lcm ( p − 1, q − 1)), en als we een niet-standaard RSA-privésleutelindeling gebruikten die alleen de absoluut minimale informatie voor decodering opsloeg (dwz n en d ), dan zou het niet mogelijk zijn om de openbare sleutel uit de privésleutel te berekenen zonder de sleutel effectief te kraken (dwz de modulus in rekening te brengen).

Inderdaad, indien gebruikt in een dergelijke niet-standaard man ner, het RSA-algoritme wordt “symmetrisch” in de zin dat geen van de sleutels ( n , e ) en ( n , d ) kan effectief worden berekend op basis van de andere en beide kunnen willekeurig worden aangeduid als de privésleutel. In principe, als u de houder van de privésleutel niet de corresponderende “openbare” sleutel liet weten (wat natuurlijk betekent dat deze niet echt meer openbaar zou zijn), dan konden ze alleen berichten ontsleutelen, maar niet versleutelen. Helaas, het praktische nut van een dergelijk schema wordt nogal beperkt door het simpele feit dat degene die het sleutelpaar genereert onvermijdelijk beide helften ervan zal kennen.

Opmerkingen

• Ik frons bij de laatste zin. Aangezien e sowieso als openbaar wordt beschouwd, kan e (en p en q) nauwelijks worden beschouwd als een achterdeur die beschikbaar is voor de eigenaar van de privésleutel. (En als een tegenstander de privésleutel d verkrijgt, heeft hij ook de openbare sleutel e en heeft hij gewonnen)
• @HagenvonEitzen: De laatste paragraaf gaat over de (niet-standaard) gebruikssituatie waarin e noch openbaar noch klein is .
• @HagenvonEitzen: Inderdaad, ik noemde dat probleem in de gekoppelde crypto.SE-post. Elk schema dat afhankelijk is van de ” openbare ” -sleutel die niet kan worden afgeleid van de ” privé ” sleutel moet noodzakelijkerwijs de ” openbare ” sleutel geheim houden voor ten minste enkele partijen ( en daarmee een van de standaardaannames van public-key crypto) schenden om dat kenmerk van enig nut te maken. Maar ik kan zien hoe die alinea misschien misleidend was; hopelijk is de herschreven versie op zijn minst een beetje duidelijker.
• RSA heeft een interessante wiskundige eigenschap dat decodering dezelfde formule gebruikt als codering, alleen met d in plaats van e. Hierdoor kunt u e en d wisselen (d.w.z. gebruik de privésleutel voor codering en de openbare sleutel voor decodering). Dan krijg je het schema voor elektronische handtekeningen.

Ja. Het is ook vrij eenvoudig. Als je naar de RSA-specificatie kijkt, heeft een openbare sleutel n en e nodig. Een privésleutel kan p q d. Gebruik deze om te berekenen.

n=p*q e=mod_inverse(d,euler_totient(n)) 

Zie https://github.com/ius/rsatool als u ze terug wilt inpakken naar een PEM-indeling

Opmerkingen

• Ingelijst als een wiskundig antwoord, dit is fout. Een privésleutel kan alleen n en d hebben, en daaruit is het onmogelijk in het algemeen om e te berekenen. Het ‘ is in de praktijk meestal alleen mogelijk omdat e bijna altijd wordt geselecteerd uit een handvol waarden. Omgerekend als een praktisch antwoord is dit fout: e is, in de praktijk altijd opgenomen bij de andere parameters (minimaal n en d, meestal ook de parameters die nodig zijn voor CRT-gebaseerde berekening).
• Akkoord, maar praktisch worden RSA met CRT private keys meestal opgeslagen als een tupel van (n, e, d, p, q, dP, dQ, qInv) wat hier het geval is. Ik probeerde gewoon de componenten wiskundig in te stellen.
• Ja: in de praktijk worden privésleutels meestal opgeslagen als een tuple die e bevat. Het is niet nodig om e te berekenen.
• @Gilles Uit de post: ” een openbare sleutel heeft n en e.” en van sudhackar ‘ s opmerking: ” maar praktisch RSA met CRT-privésleutels zijn meestal opgeslagen als een tuple van (n, e, d, p, q, dP, dQ, qlnv) “, wat me tot de conclusie brengt dat privésleutels meestal worden opgeslagen als een tuple die de privésleutel bevat. Het is niet nodig om de privésleutel te berekenen, waardoor deze hele vraag en al zijn antwoorden irrelevant zijn. Ik begrijp uw meest recente opmerking niet ‘. sudhackar ‘ s antwoord laat zien hoe je de set van mogelijke publieke sleutels kunt vinden op basis van de minst bruikbare informatie.
• @ wizzwizz4 Als je p, q en d hebt , beschikt u over meer dan de minst bruikbare informatie die mogelijk is voor een privésleutel. Ik ‘ heb nog nooit privésleutels gezien met p, q en d maar niet n en e. Je hebt n nodig om iets nuttigs te doen met de sleutel en het opslaan van p en q in plaats van n levert geen ‘ opslagruimte op.