GOSTIM: P2P F2F E2EE IM per vieną vakarą su GOST kriptografija
Būdamas kūrėju PyGOST bibliotekos (GOST kriptografiniai primityvai gryname Python), dažnai sulaukiu klausimų, kaip įdiegti paprasčiausią saugų pranešimų siuntimą ant kelio. Daugelis žmonių mano, kad taikomoji kriptografija yra gana paprasta, ir pakaks iškviesti .encrypt() blokiniame šifre, kad jį būtų galima saugiai išsiųsti ryšio kanalu. Kiti mano, kad taikomoji kriptografija yra nedaugelio žmonių likimas, ir priimtina, kad tokios turtingos įmonės kaip „Telegram“ su olimpiados matematikais negali įgyvendinti saugus protokolas.
Visa tai paskatino mane parašyti šį straipsnį, kad parodyčiau, jog kriptografinių protokolų ir saugaus MP diegimas nėra tokia sudėtinga užduotis. Tačiau neverta sugalvoti savo autentifikavimo ir pagrindinių susitarimų protokolų.
Straipsnis bus parašytas "peer-to-peer", draugas draugui, šifruojama nuo galo iki galo momentinis pasiuntinys su SIGMA-I autentifikavimo ir rakto sutarties protokolas (kurio pagrindu IPsec IKE), naudojant išskirtinai GOST kriptografinius algoritmus PyGOST biblioteka ir ASN.1 pranešimų kodavimo biblioteka PyDERASN (apie kurią aš jau rašė anksčiau). Būtina sąlyga: ji turi būti tokia paprasta, kad ją būtų galima parašyti nuo nulio per vieną vakarą (arba darbo dieną), kitaip tai nebėra paprasta programa. Tikriausiai joje yra klaidų, nereikalingų komplikacijų, trūkumų, be to, tai yra mano pirmoji programa, naudojanti asyncio biblioteką.
IM dizainas
Pirmiausia turime suprasti, kaip atrodys mūsų IM. Dėl paprastumo leiskite tai būti lygiaverčiu tinklu, neatrandant dalyvių. Asmeniškai nurodysime, kuriuo adresu: prievadu jungtis bendrauti su pašnekovu.
Suprantu, kad šiuo metu prielaida, kad galimas tiesioginis ryšys tarp dviejų savavališkų kompiuterių, yra reikšmingas IM taikymo praktikoje apribojimas. Tačiau kuo daugiau kūrėjų įdiegs visokius NAT perėjimo ramentus, tuo ilgiau liksime IPv4 internete su slegiančia tikimybe bendrauti tarp savavališkų kompiuterių. Kiek laiko galite toleruoti IPv6 trūkumą namuose ir darbe?
Turėsime draugų tinklą: visi galimi pašnekovai turi būti žinomi iš anksto. Pirma, tai labai viską supaprastina: prisistatėme, radome arba neradome vardo/rakto, atsijungėme arba tęsiame darbą, pažindami pašnekovą. Antra, apskritai jis yra saugus ir pašalina daugybę atakų.
IM sąsaja bus artima klasikiniams sprendimams neskanūs projektai, kurie man labai patinka dėl minimalizmo ir Unix būdo filosofijos. IM programa kiekvienam pašnekovui sukuria katalogą su trimis Unix domeno lizdais:
in—jame įrašomi pašnekovui siunčiami pranešimai;
out - iš jo skaitomi iš pašnekovo gauti pranešimai;
būsena – iš jos skaitydami sužinome, ar pašnekovas šiuo metu prisijungęs, ryšio adresą/prievadą.
Be to, sukuriamas conn lizdas, įrašant pagrindinio kompiuterio prievadą, į kurį inicijuojame ryšį su nuotoliniu pašnekovu.
|-- alice
| |-- in
| |-- out
| `-- state
|-- bob
| |-- in
| |-- out
| `-- state
`- conn
Šis metodas leidžia savarankiškai įgyvendinti IM transportą ir vartotojo sąsają, nes nėra draugo, negali įtikti visiems. Naudojant tmux ir (arba) daugiauodegė, galite gauti kelių langų sąsają su sintaksės paryškinimu. Ir su pagalba rlwrap galite gauti su GNU Readline suderinamą pranešimų įvesties eilutę.
Tiesą sakant, neskanūs projektai naudoja FIFO failus. Asmeniškai aš negalėjau suprasti, kaip konkurencingai dirbti su failais asinchroniškai be ranka rašyto fono iš tam skirtų gijų (aš ilgą laiką naudoju kalbą tokiems dalykams Go). Todėl nusprendžiau tenkintis su Unix domeno lizdais. Deja, dėl to neįmanoma atlikti echo 2001:470:dead::babe 6666 > conn. Aš išsprendžiau šią problemą naudodamas socat: echo 2001:470:dead::babe 6666 | socat - UNIX-CONNECT:jungtis, socat READLINE UNIX-CONNECT:alice/in.
Originalus nesaugus protokolas
TCP naudojamas kaip transportas: garantuoja pristatymą ir jo užsakymą. UDP negarantuoja nei vieno, nei kito (kas būtų naudinga, kai naudojama kriptografija), o palaikymą SCTP Python neišeina iš dėžutės.
Deja, TCP nėra pranešimo sąvokos, tik baitų srautas. Todėl būtina sugalvoti pranešimų formatą, kad jais būtų galima dalytis tarpusavyje šioje temoje. Galime sutikti naudoti eilutės tiekimo simbolį. Pradedantiesiems tai tinka, bet kai tik pradedame šifruoti savo pranešimus, šis simbolis gali pasirodyti bet kurioje šifruoto teksto vietoje. Todėl tinkluose populiarūs yra tie protokolai, kurie pirmiausia siunčia pranešimo ilgį baitais. Pavyzdžiui, „Python“ turi xdrlib, leidžiantį dirbti su panašiu formatu XDR.
Su TCP skaitymu nedirbsime teisingai ir efektyviai – supaprastinsime kodą. Mes skaitome duomenis iš lizdo begaliniu ciklu, kol iššifruojame visą pranešimą. JSON su XML taip pat gali būti naudojamas kaip šio metodo formatas. Tačiau kai pridedama kriptografija, duomenys turės būti pasirašyti ir autentifikuoti – tam reikės baitais identiško objektų atvaizdavimo, ko JSON/XML nepateikia (iškeltų rezultatai gali skirtis).
XDR tinka šiai užduočiai, tačiau aš renkuosi ASN.1 su DER kodavimu ir PyDERASN biblioteką, nes po ranka turėsime aukšto lygio objektus, su kuriais dažnai maloniau ir patogiau dirbti. Skirtingai nei beschemos bencode, MessagePack arba CBOR., ASN.1 automatiškai patikrins duomenis pagal užkoduotą schemą.
Gautas pranešimas bus Msg: arba tekstinis MsgText (kol kas su vienu teksto lauku) arba MsgHandshake rankos paspaudimo pranešimas (kuriame yra pašnekovo vardas). Dabar tai atrodo pernelyg sudėtinga, bet tai yra ateities pagrindas.
Nustatykite savo vardą (--mūsų vardas alisa). Visi laukiami pašnekovai išvardyti atskiriant kableliais (-jų vardai bob,eve). Kiekvienam pašnekovui sukuriamas katalogas su Unix lizdais, taip pat kiekvienos įėjimo, išėjimo, būsenos koruna:
Skaitydama iš būsenos lizdo, programa PEER_ALIVE žodyne ieško pašnekovo adreso. Jei dar nėra ryšio su pašnekovu, tada rašoma tuščia eilutė.
async def unixsock_state_processor(reader, writer, peer_name: str) -> None:
peer_writer = PEER_ALIVES.get(peer_name)
writer.write(
b"" if peer_writer is None else (" ".join([
str(i) for i in peer_writer.get_extra_info("peername")[:2]
]).encode("utf-8") + b"n")
)
await writer.drain()
writer.close()
Rašant adresą į jungties lizdą, paleidžiama ryšio „iniciatoriaus“ funkcija:
async def unixsock_conn_processor(reader, writer) -> None:
data = await reader.read(256)
writer.close()
host, port = data.decode("utf-8").split(" ")
await initiator(host=host, port=int(port))
Apsvarstykime iniciatorių. Pirmiausia jis akivaizdžiai atidaro ryšį su nurodytu pagrindiniu kompiuteriu / prievadu ir išsiunčia rankos paspaudimo pranešimą su savo pavadinimu:
Tada jis laukia atsakymo iš nuotolinės šalies. Bando iššifruoti gaunamą atsakymą naudodamas Msg ASN.1 schemą. Mes darome prielaidą, kad visas pranešimas bus išsiųstas viename TCP segmente ir mes jį gausime atomiškai, kai skambinsime .read(). Patikriname, ar gavome rankos paspaudimo pranešimą.
Patikriname, ar gautas pašnekovo vardas mums žinomas. Jei ne, nutraukiame ryšį. Patikriname, ar jau užmezgėme su juo ryšį (pašnekovas vėl davė komandą prisijungti prie mūsų) ir jį uždarome. Eilėje IN_QUEUES yra Python eilutės su pranešimo tekstu, tačiau turi specialią reikšmę None, kuri signalizuoja msg_sender korutinai nustoti veikti, kad ji pamirštų apie savo rašytoją, susietą su senu TCP ryšiu.
159 msg_handshake = msg.value
160 peer_name = str(msg_handshake["peerName"])
161 if peer_name not in THEIR_NAMES:
162 logging.warning("unknown peer name: %s", peer_name)
163 writer.close()
164 return
165 logging.info("%s: session established: %s", _id, peer_name)
166 # Run text message sender, initialize transport decoder {{{
167 peer_alive = PEER_ALIVES.pop(peer_name, None)
168 if peer_alive is not None:
169 peer_alive.close()
170 await IN_QUEUES[peer_name].put(None)
171 PEER_ALIVES[peer_name] = writer
172 asyncio.ensure_future(msg_sender(peer_name, writer))
173 # }}}
msg_sender priima siunčiamus pranešimus (sudėtus į eilę iš lizdo), suskirsto juos į MsgText pranešimą ir siunčia juos TCP ryšiu. Jis gali lūžti bet kurią akimirką – mes aiškiai tai perimame.
async def msg_sender(peer_name: str, writer) -> None:
in_queue = IN_QUEUES[peer_name]
while True:
text = await in_queue.get()
if text is None:
break
writer.write(Msg(("text", MsgText((
("text", UTF8String(text)),
)))).encode())
try:
await writer.drain()
except ConnectionResetError:
del PEER_ALIVES[peer_name]
return
logging.info("%s: sent %d characters message", peer_name, len(text))
Pabaigoje iniciatorius įveda begalinę pranešimų skaitymo kilpą iš lizdo. Patikrina, ar šios žinutės yra tekstinės žinutės, ir įdeda jas į OUT_QUEUES eilę, iš kurios bus siunčiamos į atitinkamo pašnekovo išvesties lizdą. Kodėl negalite tiesiog padaryti .read() ir iššifruoti pranešimo? Nes gali būti, kad kelios vartotojo žinutės bus sukauptos operacinės sistemos buferyje ir išsiųstos viename TCP segmente. Mes galime iššifruoti pirmąjį, o tada dalis sekančio gali likti buferyje. Esant bet kokiai neįprastai situacijai, mes uždarome TCP ryšį ir sustabdome msg_sender korutine (į OUT_QUEUES eilę nusiųsdami None).
174 buf = b""
175 # Wait for test messages {{{
176 while True:
177 data = await reader.read(MaxMsgLen)
178 if data == b"":
179 break
180 buf += data
181 if len(buf) > MaxMsgLen:
182 logging.warning("%s: max buffer size exceeded", _id)
183 break
184 try:
185 msg, tail = Msg().decode(buf)
186 except ASN1Error:
187 continue
188 buf = tail
189 if msg.choice != "text":
190 logging.warning("%s: unexpected %s message", _id, msg.choice)
191 break
192 try:
193 await msg_receiver(msg.value, peer_name)
194 except ValueError as err:
195 logging.warning("%s: %s", err)
196 break
197 # }}}
198 logging.info("%s: disconnecting: %s", _id, peer_name)
199 IN_QUEUES[peer_name].put(None)
200 writer.close()
66 async def msg_receiver(msg_text: MsgText, peer_name: str) -> None:
67 text = str(msg_text["text"])
68 logging.info("%s: received %d characters message", peer_name, len(text))
69 await OUT_QUEUES[peer_name].put(text)
Grįžkime prie pagrindinio kodo. Sukūrę visas korutinas tuo metu, kai programa paleidžiama, paleidžiame TCP serverį. Kiekvienam užmegztam ryšiui sukuriama atsakiklio koruna.
logging.basicConfig(
level=logging.INFO,
format="%(levelname)s %(asctime)s: %(funcName)s: %(message)s",
)
loop = asyncio.get_event_loop()
server = loop.run_until_complete(asyncio.start_server(responder, args.bind, args.port))
logging.info("Listening on: %s", server.sockets[0].getsockname())
loop.run_forever()
atsakiklis yra panašus į iniciatorių ir atspindi visus tuos pačius veiksmus, tačiau begalinis pranešimų skaitymo ciklas paprastumo dėlei prasideda iš karto. Šiuo metu rankos paspaudimo protokolas siunčia po vieną žinutę iš abiejų pusių, tačiau ateityje bus dvi iš ryšio iniciatoriaus, po kurių iškart bus galima siųsti trumpąsias žinutes.
Atėjo laikas apsaugoti mūsų ryšius. Ką reiškia saugumas ir ko norime:
perduodamų pranešimų konfidencialumas;
perduodamų pranešimų autentiškumas ir vientisumas – turi būti aptikti jų pokyčiai;
apsauga nuo pakartojimo atakų – turi būti nustatytas trūkstamų arba pasikartojančių pranešimų faktas (ir mes nusprendžiame nutraukti ryšį);
pašnekovų identifikavimas ir autentifikavimas naudojant iš anksto įvestus viešuosius raktus – jau anksčiau nusprendėme, kad kuriame draugas-draugui tinklą. Tik po autentifikavimo suprasime, su kuo bendraujame;
prieinamumas tobulas išankstinis slaptumas ypatybės (PFS) – pažeidžiant mūsų ilgaamžį pasirašymo raktą neturėtų atsirasti galimybė perskaityti visą ankstesnę korespondenciją. Perimto srauto įrašymas tampa nenaudingas;
pranešimų (transportavimo ir rankos paspaudimo) galiojimas / galiojimas tik per vieną TCP seansą. Teisingai pasirašytų/autentifikuotų pranešimų įterpimas iš kitos sesijos (net su tuo pačiu pašnekovu) neturėtų būti įmanomas;
pasyvus stebėtojas neturėtų matyti nei vartotojo identifikatorių, nei perduotų ilgalaikių viešųjų raktų, nei maišos iš jų. Tam tikras anonimiškumas iš pasyvaus stebėtojo.
Keista, bet beveik visi nori turėti šį minimumą bet kuriame rankos paspaudimo protokole, o „naminių“ protokolų atveju labai mažai iš aukščiau paminėtų dalykų. Dabar nieko naujo nesugalvosime. Tikrai rekomenduočiau naudoti Triukšmo karkasas pastatymo protokolams, bet renkamės ką nors paprastesnio.
Du populiariausi protokolai yra šie:
TLS - labai sudėtingas protokolas, turintis ilgą klaidų, strigčių, pažeidžiamumų, prasto mąstymo, sudėtingumo ir trūkumų istoriją (tačiau tai mažai ką bendro su TLS 1.3). Bet mes to nesvarstome, nes tai per daug sudėtinga.
IPsec с IKE — neturi rimtų kriptografinių problemų, nors jos taip pat nėra paprastos. Jei skaitote apie IKEv1 ir IKEv2, tada jų šaltinis yra STS, ISO/IEC IS 9798-3 ir SIGMA (SIGn-and-MAc) protokolai – pakankamai paprasti, kad juos būtų galima įdiegti per vieną vakarą.
Kuo naudinga SIGMA, kaip naujausia STS/ISO protokolų kūrimo grandis? Jis atitinka visus mūsų reikalavimus (įskaitant pašnekovo identifikatorių „slėpimą“) ir neturi žinomų kriptografinių problemų. Jis yra minimalistinis – pašalinus bent vieną elementą iš protokolo pranešimo, jis bus nesaugus.
Nuo paprasčiausio namuose auginamo protokolo pereikime prie SIGMA. Pati pagrindinė mus dominanti operacija yra pagrindinis susitarimas: funkcija, kuri išveda abiem dalyviams tą pačią reikšmę, kurią galima naudoti kaip simetrinį raktą. Nesileidžiant į smulkmenas: kiekviena iš šalių sukuria trumpalaikę (naudojamą tik per vieną seansą) raktų porą (viešuosius ir privačius raktus), keičiasi viešaisiais raktais, iškviečia susitarimo funkciją, kurios įėjimui perduoda savo privatųjį raktą ir viešąjį. pašnekovo raktas.
Kiekvienas gali peršokti per vidurį ir pakeisti viešuosius raktus savo – pašnekovų autentifikavimo šiame protokole nėra. Pridėkime parašą su ilgaamžiais raktais.
Toks parašas neveiks, nes jis nesusietas su konkrečia sesija. Tokie pranešimai taip pat „tinka“ seansams su kitais dalyviais. Visas kontekstas turi pasirašyti. Tai verčia mus taip pat pridėti dar vieną pranešimą nuo A.
Be to, labai svarbu po parašu pridėti savo identifikatorių, nes kitu atveju galime pakeisti IdXXX ir iš naujo pasirašyti pranešimą kito žinomo pašnekovo raktu. Apsaugoti refleksijos priepuoliai, būtina, kad elementai po parašu būtų aiškiai apibrėžtose vietose pagal savo reikšmę: jei A žymi (PubA, PubB), tai B turi pasirašyti (PubB, PubA). Tai taip pat byloja apie nuosekliųjų duomenų struktūros ir formato pasirinkimo svarbą. Pavyzdžiui, ASN.1 DER kodavimo rinkiniai yra rūšiuojami: SET OF(PubA, PubB) bus identiškas SET OF(PubB, PubA).
Tačiau mes vis dar neįrodėme, kad šiai sesijai sukūrėme tą patį bendrinamą raktą. Iš principo galime apsieiti ir be šio žingsnio – nebegalios pats pirmas transporto susisiekimas, bet norime, kad baigus rankos paspaudimą būtume tikri, kad dėl visko tikrai sutarta. Šiuo metu turime ISO/IEC IS 9798-3 protokolą.
Galėtume pasirašyti patį sugeneruotą raktą. Tai pavojinga, nes gali būti, kad naudojamas parašo algoritmas gali nutekėti (nors ir bitai per parašą, bet vis tiek nutekėjimas). Galima pasirašyti išvedimo rakto maišą, tačiau net išvestinio rakto maišos nutekėjimas gali būti vertingas brutaliosios jėgos atakoje prieš išvedimo funkciją. SIGMA naudoja MAC funkciją, kuri patvirtina siuntėjo ID.
Siekiant optimizavimo, kai kurie gali norėti pakartotinai naudoti savo trumpalaikius raktus (o tai, žinoma, gaila PFS). Pavyzdžiui, sugeneravome raktų porą, bandėme prisijungti, bet TCP nepasiekiamas arba buvo nutrauktas kažkur protokolo viduryje. Gaila švaistyti švaistomus entropijos ir procesoriaus išteklius naujai porai. Todėl pristatysime taip vadinamą slapuką – pseudoatsitiktinę reikšmę, kuri apsaugos nuo galimų atsitiktinių pakartojimų atakų pakartotinai naudojant trumpalaikius viešuosius raktus. Dėl slapuko ir trumpalaikio viešojo rakto susiejimo priešingos šalies viešasis raktas gali būti pašalintas iš parašo kaip nereikalingas.
Galiausiai norime gauti savo pokalbio partnerių privatumą iš pasyvaus stebėtojo. Norėdami tai padaryti, SIGMA siūlo pirmiausia apsikeisti trumpalaikiais raktais ir sukurti bendrą raktą, kuriuo būtų galima užšifruoti autentifikavimo ir identifikavimo pranešimus. SIGMA aprašo dvi parinktis:
SIGMA-I - apsaugo iniciatorių nuo aktyvių atakų, atsakytoją nuo pasyviųjų: iniciatorius autentifikuoja atsakytoją ir jei kažkas nesutampa, tai neišduoda savo identifikacijos. Kaltinamasis išduoda savo tapatybę, jei su juo pradedamas aktyvus protokolas. Pasyvus stebėtojas nieko neišmoksta;
SIGMA-R – apsaugo atsakytoją nuo aktyvių atakų, iniciatorių nuo pasyvių. Viskas yra visiškai priešingai, tačiau šiame protokole jau perduodami keturi rankos paspaudimo pranešimai.
Mes pasirenkame SIGMA-I, nes jis yra panašesnis į tai, ko tikimės iš kliento-serverio pažįstamų dalykų: klientą atpažįsta tik autentifikuotas serveris, o serverį jau žino visi. Be to, jį lengviau įgyvendinti, nes mažiau pranešama rankos paspaudimu. Viskas, ką pridedame prie protokolo, yra užšifruoti dalį pranešimo ir perkelti identifikatorių A į užšifruotą paskutinio pranešimo dalį:
GOST R naudojamas parašui 34.10-2012 algoritmas su 256 bitų raktais.
Viešajam raktui generuoti naudojamas 34.10-2012-XNUMX VKO.
CMAC naudojamas kaip MAC. Techniškai tai yra specialus blokinio šifro veikimo režimas, aprašytas GOST R 34.13-2015. Kaip šio režimo šifravimo funkcija − Žiogas (34.12-2015).
Jo viešojo rakto maiša naudojama kaip pašnekovo identifikatorius. Naudojamas kaip maišas Stribog-256 (34.11-2012-256 XNUMX bitai).
Po rankos paspaudimo susitarsime dėl bendro rakto. Galime jį naudoti autentifikuotam transportavimo pranešimų šifravimui. Ši dalis yra labai paprasta ir sunku suklysti: padidiname pranešimų skaitiklį, užšifruojame pranešimą, autentifikuojame (MAC) skaitiklį ir šifruotą tekstą, siunčiame. Gavę pranešimą patikriname, ar skaitiklis turi laukiamą reikšmę, skaitikliu autentifikuojame šifruotą tekstą ir jį iššifruojame. Kokį raktą turėčiau naudoti norint užšifruoti rankos paspaudimo pranešimus, perduoti pranešimus ir kaip juos autentifikuoti? Visoms šioms užduotims naudoti vieną raktą yra pavojinga ir neprotinga. Būtina generuoti raktus naudojant specializuotas funkcijas KDF (raktų išvedimo funkcija). Vėlgi, neskaldykime plaukų ir nieko nesugalvokime: HKDF jau seniai žinomas, gerai ištirtas ir neturi jokių žinomų problemų. Deja, gimtoji Python biblioteka šios funkcijos neturi, todėl naudojame hkdf plastikinis maišelis. HKDF naudoja viduje HMAC, kuri savo ruožtu naudoja maišos funkciją. „Python“ diegimo pavyzdys Vikipedijos puslapyje užima vos kelias kodo eilutes. Kaip ir 34.10-2012-256 atveju, kaip maišos funkciją naudosime Stribog-XNUMX. Mūsų rakto susitarimo funkcijos išvestis bus vadinama seanso raktu, iš kurio bus generuojami trūkstami simetriški:
Bus pasirašyta HandshakeTBS. HandshakeTBE – kas bus užšifruota. Atkreipiu jūsų dėmesį į ukm lauką MsgHandshake1. 34.10 VKO, siekiant dar didesnio generuojamų raktų atsitiktinio atskyrimo, apima UKM (vartotojo įrakinimo medžiagos) parametrą – tik papildomą entropiją.
Kriptografijos pridėjimas prie kodo
Apsvarstykime tik pradinio kodo pakeitimus, nes sistema išliko ta pati (tiesą sakant, pirmiausia buvo parašytas galutinis įgyvendinimas, o tada iš jo buvo iškirpta visa kriptografija).
Kadangi pašnekovų autentifikavimas ir identifikavimas bus atliekami naudojant viešuosius raktus, dabar juos reikia kažkur saugoti ilgą laiką. Dėl paprastumo naudojame JSON taip:
mūsų – mūsų raktų pora, šešioliktainiai privatūs ir viešieji raktai. jų — pašnekovų vardai ir jų viešieji raktai. Pakeiskime komandinės eilutės argumentus ir pridėkime JSON duomenų papildomą apdorojimą:
from pygost import gost3410
from pygost.gost34112012256 import GOST34112012256
CURVE = gost3410.GOST3410Curve(
*gost3410.CURVE_PARAMS["GostR3410_2001_CryptoPro_A_ParamSet"]
)
parser = argparse.ArgumentParser(description="GOSTIM")
parser.add_argument(
"--keys-gen",
action="store_true",
help="Generate JSON with our new keypair",
)
parser.add_argument(
"--keys",
default="keys.json",
required=False,
help="JSON with our and their keys",
)
parser.add_argument(
"--bind",
default="::1",
help="Address to listen on",
)
parser.add_argument(
"--port",
type=int,
default=6666,
help="Port to listen on",
)
args = parser.parse_args()
if args.keys_gen:
prv_raw = urandom(32)
pub = gost3410.public_key(CURVE, gost3410.prv_unmarshal(prv_raw))
pub_raw = gost3410.pub_marshal(pub)
print(json.dumps({
"our": {"prv": hexenc(prv_raw), "pub": hexenc(pub_raw)},
"their": {},
}))
exit(0)
# Parse and unmarshal our and their keys {{{
with open(args.keys, "rb") as fd:
_keys = json.loads(fd.read().decode("utf-8"))
KEY_OUR_SIGN_PRV = gost3410.prv_unmarshal(hexdec(_keys["our"]["prv"]))
_pub = hexdec(_keys["our"]["pub"])
KEY_OUR_SIGN_PUB = gost3410.pub_unmarshal(_pub)
KEY_OUR_SIGN_PUB_HASH = OctetString(GOST34112012256(_pub).digest())
for peer_name, pub_raw in _keys["their"].items():
_pub = hexdec(pub_raw)
KEYS[GOST34112012256(_pub).digest()] = {
"name": peer_name,
"pub": gost3410.pub_unmarshal(_pub),
}
# }}}
34.10 algoritmo privatusis raktas yra atsitiktinis skaičius. 256 bitų dydis 256 bitų elipsinėms kreivėms. PyGOST veikia ne su baitų rinkiniu, o su dideli skaičiai, todėl mūsų privatus raktas (urandom(32)) turi būti konvertuojamas į skaičių naudojant gost3410.prv_unmarshal(). Viešasis raktas nustatomas deterministiškai iš privataus rakto naudojant gost3410.public_key(). Viešasis raktas 34.10 yra du dideli skaičiai, kuriuos taip pat reikia konvertuoti į baitų seką, kad būtų lengviau saugoti ir perduoti naudojant gost3410.pub_marshal().
Perskaičius JSON failą, viešuosius raktus reikia konvertuoti atgal naudojant gost3410.pub_unmarshal(). Kadangi pašnekovų identifikatorius gausime maišos pavidalu iš viešojo rakto, juos galima iš karto iš anksto apskaičiuoti ir įdėti į žodyną greitai paieškai. Stribog-256 maiša yra gost34112012256.GOST34112012256(), kuri visiškai atitinka maišos funkcijų maišos sąsają.
Kaip pasikeitė iniciatoriaus koruna? Viskas pagal rankos paspaudimo schemą: sugeneruojame slapuką (128 bitų pakanka), trumpalaikę raktų porą 34.10, kuri bus naudojama VKO rakto susitarimo funkcijai.
UKM yra 64 bitų skaičius (urandom (8)), kuris taip pat reikalauja deserializacijos iš jo baitų atvaizdavimo naudojant gost3410_vko.ukm_unmarshal(). 34.10-2012-256 3410 bitų VKO funkcija yra gost34102012256_vko.kek_XNUMX() (KEK - šifravimo raktas).
Sugeneruotas seanso raktas jau yra 256 bitų pseudoatsitiktinė baitų seka. Todėl jis gali būti nedelsiant naudojamas HKDF funkcijose. Kadangi GOST34112012256 atitinka hashlib sąsają, ją galima iš karto naudoti Hkdf klasėje. Druskos nenurodome (pirmasis Hkdf argumentas), nes sugeneruotas raktas dėl dalyvaujančių raktų porų trumpalaikiškumo kiekvienoje sesijoje skirsis ir jame jau yra pakankamai entropijos. Pagal numatytuosius nustatymus kdf.expand() jau sukuria 256 bitų raktus, reikalingus Grasshopper vėliau.
Tada patikrinamos gaunamo pranešimo TBE ir TBS dalys:
apskaičiuojamas ir patikrinamas gaunamo šifruoto teksto MAC;
šifruotas tekstas iššifruojamas;
TBE struktūra iššifruojama;
iš jo paimamas pašnekovo identifikatorius ir patikrinama, ar jis mums apskritai žinomas;
MAC per šį identifikatorių apskaičiuojamas ir patikrinamas;
patikrinamas parašas per TBS struktūrą, į kurį įtrauktas abiejų šalių slapukas ir priešingos šalies viešasis trumpalaikis raktas. Parašas patikrinamas ilgaamžiu pašnekovo parašo raktu.
Kaip rašiau aukščiau, 34.13-2015-XNUMX aprašo įvairius blokinio šifro veikimo režimai nuo 34.12-2015-3413. Tarp jų yra imitacinių įdėklų generavimo ir MAC skaičiavimų režimas. PyGOST tai gost34.12.mac(). Šis režimas reikalauja perduoti šifravimo funkciją (gauti ir grąžinti vieną duomenų bloką), šifravimo bloko dydį ir, tiesą sakant, pačius duomenis. Kodėl negalite užkoduoti šifravimo bloko dydžio? 2015-128-64 aprašomas ne tik XNUMX bitų Grasshopper šifras, bet ir XNUMX bitų Magma - šiek tiek pakeistas GOST 28147-89, sukurtas dar KGB ir vis dar turi vieną aukščiausių saugos slenksčių.
Kuznechik inicijuojamas skambinant gost.3412.GOST3412Kuznechik(key) ir grąžinamas objektas su .encrypt()/.decrypt() metodais, tinkančiais pereiti prie 34.13 funkcijų. MAC apskaičiuojamas taip: gost3413.mac(GOST3412Kuznechik(key).encrypt, KUZNECHIK_BLOCKSIZE, šifruotas tekstas). Norėdami palyginti apskaičiuotą ir gautą MAC, negalite naudoti įprasto baitų eilučių palyginimo (==), nes ši operacija praleidžia palyginimo laiką, o tai paprastai gali sukelti mirtinus pažeidžiamumus, pvz. BEAST atakų prieš TLS. Python tam turi specialią funkciją hmac.compare_digest.
Bloko šifravimo funkcija gali užšifruoti tik vieną duomenų bloką. Didesniam skaičiui ir net ne kartotiniam ilgiui būtina naudoti šifravimo režimą. 34.13-2015 aprašoma: ECB, CTR, OFB, CBC, CFB. Kiekvienas iš jų turi savo priimtinas taikymo sritis ir charakteristikas. Deja, mes vis dar neturime standartizuotų autentifikuoti šifravimo režimai (pvz., CCM, OCB, GCM ir panašiai) – esame priversti bent jau patys pridėti MAC. aš renkuosi skaitiklio režimas (CTR): nereikalauja užpildymo pagal bloko dydį, gali būti lygiagretinamas, naudojama tik šifravimo funkcija, gali būti saugiai naudojamas šifruoti daug pranešimų (skirtingai nei CBC, kuris gana greitai susiduria su susidūrimais).
Kaip ir .mac(), .ctr() naudoja panašią įvestį: šifruotas tekstas = gost3413.ctr(GOST3412Kuznechik(key).encrypt, KUZNECHIK_BLOCKSIZE, paprastas tekstas, iv). Būtina nurodyti inicijavimo vektorių, kuris yra lygiai pusė šifravimo bloko ilgio. Jei mūsų šifravimo raktas naudojamas tik vienam pranešimui užšifruoti (nors ir iš kelių blokų), tada saugu nustatyti nulinį iniciacijos vektorių. Norėdami užšifruoti rankos paspaudimo pranešimus, kiekvieną kartą naudojame atskirą raktą.
Parašo tikrinimas gost3410.verify() yra trivialus: praeiname elipsinę kreivę, kurioje dirbame (tiesiog įrašome ją į savo GOSTIM protokolą), pasirašančiojo viešąjį raktą (nepamirškite, kad tai turėtų būti dviejų eilė dideli skaičiai, o ne baitų eilutė), 34.11-2012-XNUMX maišos ir pats parašas.
Toliau iniciatoriuje paruošiame ir išsiunčiame rankos paspaudimo pranešimą handshake2, atlikdami tuos pačius veiksmus, kaip ir tikrinimo metu, tik simetriškai: pasirašome ant savo raktų, o ne tikriname ir t.t.
Korutina msg_sender dabar užšifruoja pranešimus prieš siųsdama juos TCP ryšiu. Kiekvienas pranešimas turi monotoniškai didėjantį nonce, kuris taip pat yra inicijavimo vektorius, kai šifruojamas skaitiklio režimu. Garantuojama, kad kiekvienas pranešimas ir pranešimų blokas turės skirtingą skaitiklio reikšmę.
GOSTIM skirtas naudoti tik švietimo tikslais (kadangi bent jau nėra testų)! Programos šaltinio kodą galima atsisiųsti čia (Стрибог-256 хэш: 995bbd368c04e50a481d138c5fa2e43ec7c89bc77743ba8dbabee1fde45de120). Как и все мои проекты, типа GoGOST, PyDERASN, NCCP, GoVPN, GOSTIM yra visiškai nemokama programinė įranga, platinamas pagal sąlygas GPLv3 +.