Denne artikkelen om Mtprotos ende-til-ende-kryptering er ment for avanserte brukere.Hvis Du vil lære Mer Om Hemmelige Chatter fra en mindre skremmende kilde, vennligst se vår generelle FAQ.
Merk at fra og med versjon 4.6 bruker store Telegramklienter MTProto 2.0.MTProto v. 1. 0 er utdatert og blir for tiden faset ut.
Hemmelige Chatter Er en-til-en-chatter der meldinger krypteres med en nøkkel som bare holdes av chattens deltakere. Merk at skjemaet for disse ende-til-ende krypterte Hemmelige Chatter er forskjellig fra det som brukes for sky chatter:
et notat På MTProto 2.0
denne artikkelen beskriver ende-til-ende krypteringslag I MTProto protokollversjon 2.0.De viktigste forskjellene fra versjon 1.0 (beskrevet her som referanse) er som følger:
- SHA-256 brukes i stedet FOR SHA-1;
- Padding bytes er involvert i beregningen av msg_key;
- msg_key avhenger ikke bare av meldingen som skal krypteres, men også på en del av den hemmelige chat-tasten;
- 12..1024 padding byte brukes i stedet for 0..15 polstring byte i v. 1. 0.
Se Også: MTProto 2.0: Cloud Chats, server-klient kryptering
Nøkkelgenerering
Nøkler genereres ved Hjelp Av Diffie-Hellman-protokollen.
la Oss vurdere følgende scenario: Bruker a ønsker å starte ende-til-ende kryptert kommunikasjon Med Bruker B.
Sende En Forespørsel
Bruker a utfører meldinger.getDhConfig for Å oppnå Diffie-Hellman-parametrene: en primær p og et høyordenselement g.
Å Utføre denne metoden før hver ny nøkkelgenereringsprosedyre er av avgjørende betydning. Det er fornuftig å cache verdiene til parametrene sammen med versjonen for å unngå å måtte motta alle verdiene hver gang. Hvis versjonen som er lagret på klienten, fortsatt er oppdatert, returnerer serveren konstruktørmeldingene.dhConfigNotModified.
Klienten forventes å sjekke om p er en sikker 2048-bit prime (som betyr at både p og (p-1)/2 er prime, og at 2^2047 < p < 2^2048), og at g genererer en syklisk undergruppe av prime order (p-1)/2, dvs. er en kvadratisk rest mod p. siden g alltid er lik 2, 3, 4, 5, 6 eller 7, gjøres dette enkelt ved hjelp av kvadratisk gjensidighetslov, noe som gir en enkel betingelse på p mod 4g-nemlig p mod 8 = 7 for g = 2; p mod 3 = 2 for g = 3; ingen ekstra betingelse for g = 4; p mod 5 = 1 eller 4 for g = 5; p mod 24 = 19 eller 23 for g = 6; og p mod 7 = 3, 5 eller 6 for g = 7. Etter at g og p har blitt sjekket av klienten, er det fornuftig å cache resultatet, for å unngå å gjenta lange beregninger i fremtiden. Denne hurtigbufferen kan deles med en som brukes Til Autorisasjonsnøkkelgenerering.
hvis klienten har en utilstrekkelig tilfeldig tallgenerator, er det fornuftig å passere random_length-parameteren (random_length> 0) slik at serveren genererer sin egen tilfeldige sekvens tilfeldig av riktig lengde.Viktig: bruk av serverens tilfeldige sekvens i sin råform kan være usikker. Den må kombineres med en klientsekvens, for eksempel ved å generere et klient tilfeldig tall med samme lengde (client_random) og bruke final_random := random XOR client_random.Klient a beregner et 2048-biters nummer a (bruker tilstrekkelig entropi eller serverens tilfeldige, se ovenfor) og utfører meldinger.requestEncryption etter å ha passert i g_a := pow(g, a) mod dh_prime.
Bruker b mottar oppdateringen updateEncryption for alle tilknyttede autorisasjonsnøkler (alle autoriserte enheter) med chat-konstruktøren encryptedChatRequested. Brukeren må vises grunnleggende informasjon Om Bruker A og må bli bedt om å godta eller avvise forespørselen.
begge klientene skal kontrollere at g, g_a og g_b er større enn en og mindre enn p-1. Vi anbefaler at g_a og g_b er mellom 2^{2048-64} og p – 2^{2048-64} også.
Godta En Forespørsel
Etter At Bruker B bekrefter opprettelsen av en hemmelig chat Med a i klientgrensesnittet, Mottar Klient B også oppdaterte konfigurasjonsparametere For Diffie-Hellman-metoden. Deretter genererer det et tilfeldig 2048-bit tall, b, ved hjelp av regler som ligner de for a.
etter å ha mottatt g_a fra oppdateringen med encryptedChatRequested, kan den umiddelbart generere den endelige delte nøkkelen: key = (pow(g_a, b) mod dh_prime). Hvis nøkkellengde < 256 byte, legg til flere innledende nullbyte som polstring – slik at nøkkelen er nøyaktig 256 byte lang. Fingeravtrykket, key_fingerprint, er lik DE 64 siste bitene AV SHA1 (nøkkel).
Merk 1: I dette tilfellet SHA1 brukes her selv For MTProto 2.0 hemmelige samtaler.
Notat 2: dette fingeravtrykket brukes som en sunnhetskontroll for nøkkelutvekslingsprosedyren for å oppdage feil når du utvikler klientprogramvare — det er ikke koblet til nøkkelvisualiseringen som brukes på klientene som middel til ekstern godkjenning i hemmelige chatter. Nøkkelvisualiseringer på klientene genereres ved hjelp av DE første 128 bitene SHA1 (innledende nøkkel) etterfulgt av de første 160 bitene SHA256 (nøkkel brukt når secret chat ble oppdatert til lag 46).
Klient b utfører meldinger.acceptEncryption etter å ha passert den g_b := pow(g, b) mod dh_prime og key_fingerprint.
for Alle Klient B autoriserte enheter, bortsett fra den nåværende, updateEncryption oppdateringer sendes med konstruktøren encryptedChatDiscarded. Deretter Er Den eneste enheten som vil kunne få tilgang til den hemmelige chatten, Enhet B, som ringte til meldinger.aksepterkryptering.
Bruker A vil bli sendt en updateEncryption update med konstruktøren encryptedChat, for autorisasjonsnøkkelen som startet chatten.Med g_b fra oppdateringen kan Klient a også beregne den delte nøkkelen key = (pow(g_b, a) mod dh_prime). Hvis nøkkellengde < 256 byte, legg til flere innledende nullbyte som polstring – slik at nøkkelen er nøyaktig 256 byte lang. Hvis fingeravtrykket for den mottatte nøkkelen er identisk med den som ble sendt til kryptertchat, innkommende meldinger kan sendes og behandles. Ellers, meldinger.discardEncryption må utføres og brukeren varslet.
Perfect Forward Secrecy
for å holde tidligere kommunikasjon trygg, vil offisielle Telegram-klienter starte re-keying når en nøkkel har blitt brukt til å dekryptere og kryptere mer enn 100 meldinger, eller har vært i bruk i mer enn en uke, forutsatt at nøkkelen har blitt brukt til å kryptere minst en melding. Gamle nøkler blir så sikkert kassert og kan ikke rekonstrueres, selv med tilgang til de nye nøklene som er i bruk.
protokollen for ny tasting er nærmere beskrevet i denne artikkelen: Perfekt Hemmelighold i Hemmelige Samtaler.
Vær oppmerksom på at klienten må støtte Videresending Hemmelighold I Hemmelige Samtaler for å være kompatibel med offisielle Telegram klienter.
Sende Og Motta Meldinger I En Hemmelig Chat
Serialisering og Kryptering Av Utgående Meldinger
Et Tl-objekt Av typen Dekryptertmelding opprettes og inneholder meldingen i ren tekst. For bakoverkompatibilitet må objektet pakkes inn i konstruktøren dekryptertmelding med en indikasjon på det støttede laget (begynner med 46).
TL-Skjemaet for innholdet i ende-til-ende krypterte meldinger er tilgjengelig her »
den resulterende konstruksjonen er serialisert som en rekke byte ved hjelp av generiske tl-regler. Den resulterende matrisen er prepended av 4 byte som inneholder arraylengden som ikke teller disse 4 byte. byte-matrisen er polstret med 12 til 1024 tilfeldig polstring byte for å gjøre lengden delelig med 16 byte. (I den eldre MTProto 1.0 kryptering, bare 0 til 15 padding byte ble brukt.)
Meldingsnøkkel, msg_key, beregnes som DE 128 midterste bitene I SHA256 av dataene som ble oppnådd i forrige trinn, med 32 byte fra den delte nøkkelen. (For Den eldre MTProto 1.0-kryptering ble msg_key beregnet annerledes, som de 128 nedre bitene AV SHA1 av dataene som ble oppnådd i de forrige trinnene, unntatt padding bytes.)
For MTProto 2.0 beregnes aes-nøkkelen aes_key og initialiseringsvektoren aes_iv ( nøkkel er den delte nøkkelen oppnådd under Nøkkelgenerering) som følger: msg_key_large = SHA256 (substr (nøkkel, 88 + x, 32) + ren tekst + random_padding);
for mtproto 2.0, x=0 for meldinger fra opphavsmannen til den hemmelige chatten, x=8 for meldingene i motsatt retning.
For den foreldede MTProto 1.0, msg_key, aes_key og aes_iv ble beregnet forskjellig (se dette dokumentet for referanse).Data krypteres med en 256-biters nøkkel, aes_key og en 256-biters initialiseringsvektor, aes-iv, ved HJELP AV aes-256-kryptering med infinite garble extension (ige). Krypteringsnøkkel fingeravtrykk key_fingerprint og meldingsnøkkelen msg_key legges på toppen av den resulterende byte array.
Krypterte data er innebygd i en melding.SENDENCRYPTED API call og sendt Til Telegram server for levering Til Den Andre parten Av Secret Chat.
Oppgradering Til MTProto 2.0 Fra MTProto 1.0
så snart begge parter i en hemmelig chat bruker Minst Lag 73, bør De bare bruke MTProto 2.0 for alle utgående meldinger. Noen av de første mottatte meldingene kan bruke MTProto 1.0, hvis et tilstrekkelig høyt startlag ikke har blitt forhandlet under opprettelsen av den hemmelige chatten. Etter at Den første meldingen kryptert Med MTProto 2.0 (eller den første meldingen Med Lag 73 eller høyere) er mottatt, må alle meldinger med høyere sekvensnumre krypteres Med MTProto 2.0 også.
så lenge det nåværende laget er lavere enn 73, bør hver part prøve å dekryptere mottatte meldinger Med MTProto 1.0, og hvis dette ikke lykkes (msg_key ikke samsvarer), prøv MTProto 2.0. Når Den første MTProto 2.0-krypterte meldingen kommer (eller laget er oppgradert til 73), er det ikke nødvendig å prøve MTProto 1.0 dekryptering for noen av de ytterligere meldingene (med mindre klienten fortsatt venter på at noen hull skal lukkes).
Dekryptere En Innkommende Melding
trinnene ovenfor utføres i omvendt rekkefølge. Når en kryptert melding er mottatt, må du kontrollere at msg_key faktisk er lik DE 128 midterste bitene I SHA256-hashen for den dekrypterte meldingen, med 32 byte tatt fra den delte nøkkelen.Hvis meldingslaget er større enn det som støttes av klienten, må brukeren varsles om at klientversjonen er utdatert og bedt om å oppdatere.
Sekvensnumre
det er nødvendig å tolke alle meldinger i sin opprinnelige rekkefølge for å beskytte mot mulige manipulasjoner. Hemmelige chatter støtter en spesiell mekanisme for å håndtere seq_no tellere uavhengig av serveren.
Riktig håndtering av disse tellerne er nærmere beskrevet i denne artikkelen: Sekvensnumre I Hemmelige Chatter.
vær oppmerksom på at klienten din må støtte sekvensnumre I Hemmelige Chatter for å være kompatibel med offisielle Telegram-klienter.
Sende Krypterte Filer
alle filer som sendes til hemmelige chatter, krypteres med engangsnøkler som ikke på noen måte er relatert til chatens delte nøkkel. Før en kryptert fil sendes, antas det at den krypterte filens adresse vil bli festet på utsiden av en kryptert melding ved hjelp av filparameteren til meldingene.sendEncryptedFile metode og at nøkkelen for direkte dekryptering vil bli sendt i kroppen av meldingen (nøkkelen parameter i konstruktører decryptedMessageMediaPhoto, decryptedMessageMediaVideo og decryptedMessageMediaFile.
før en fil sendes til en hemmelig chat, beregnes 2 tilfeldige 256-biters tall som vil fungere SOM aes-nøkkel og initialiseringsvektor som brukes til å kryptere filen. AES – 256 kryptering med infinite garble extension (ige) brukes på samme måte.
nøkkelfingeravtrykket beregnes som følger:
- digest = md5(key + iv)
- fingeravtrykk = substr (digest, 0, 4) XOR substr(digest, 4, 4)
det krypterte innholdet i en fil lagres på serveren på omtrent samme måte som for en fil i skychatter: bit for bit bruker samtaler for å laste opp.lagre filepart.En påfølgende samtale til meldinger.sendEncryptedFile vil tildele en identifikator til den lagrede filen og sende adressen sammen med meldingen. Mottakeren vil motta en oppdatering med kryptertmelding, og filparameteren vil inneholde filinformasjon.Innkommende og utgående krypterte filer kan videresendes til andre hemmelige samtaler ved hjelp av constructor inputEncryptedFile for å unngå å lagre det samme innholdet på serveren to ganger.
Arbeide med En Oppdateringsboks
Hemmelige chatter er knyttet til bestemte enheter (eller rettere med autorisasjonsnøkler), ikke brukere. En vanlig meldingsboks, som bruker pts til å beskrive klientens status, er ikke egnet, fordi den er designet for langsiktig meldingslagring og meldingstilgang fra forskjellige enheter.
en ekstra midlertidig meldingskø innføres som en løsning på dette problemet. Når en oppdatering om en melding fra en hemmelig chat sendes, sendes en ny verdi av qts, som bidrar til å rekonstruere forskjellen hvis det har vært en lang pause i forbindelsen eller i tilfelle tap av en oppdatering.
som antall hendelser øker, verdien av qts øker med 1 med hver ny hendelse. Den opprinnelige verdien kan ikke (og vil ikke) være lik 0.
det faktum at hendelser fra den midlertidige køen er mottatt og lagret av klienten, bekreftes eksplisitt av et anrop til meldingene.receivedQueue metode eller implisitt ved a ringe til oppdateringer.getDifference(verdien av qts passert, ikke den endelige tilstanden). Alle meldinger anerkjent som levert av klienten, samt eventuelle meldinger eldre enn 7 dager, kan (og vil) bli slettet fra serveren.
ved de-autorisasjon vil hendelseskøen til den tilsvarende enheten bli tvingt slettet, og verdien av qts blir irrelevant.
Oppdatering til nye lag
klienten din bør alltid lagre det maksimale laget som er kjent for å støttes av klienten på den andre siden av en hemmelig chat. Når den hemmelige chatten først opprettes, bør denne verdien initialiseres til 46. Denne eksterne lagverdien må alltid oppdateres umiddelbart etter mottak av en pakke som inneholder informasjon om et øvre lag, dvs.:
- enhver hemmelig chatmelding som inneholder layer_no i sin
decryptedMessageLayermed lag>=46, eller - en decryptedMessageActionNotifyLayer-tjenestemelding, pakket inn som om det var decryptedMessageService-konstruktøren av det foreldede laget 8 (konstruktør
decryptedMessageService#aa48327d).
Varsle den eksterne klienten om ditt lokale lag
for å varsle den eksterne klienten om ditt lokale lag, må klienten sende en melding av typendecryptedMessageActionNotifyLayer. Denne meldingen ma pakkes inn i en konstruktor av et passende lag.
det er to tilfeller når klienten din må varsle den eksterne klienten om sitt lokale lag:
- Så snart en ny hemmelig chat er opprettet, umiddelbart etter at den hemmelige nøkkelen har blitt utvekslet.
- Umiddelbart Etter at den lokale klienten har blitt oppdatert for å støtte et nytt hemmelig chatlag. I dette tilfellet må meldinger sendes til alle eksisterende hemmelige chatter. Merk at dette bare er nødvendig når du oppdaterer til nye lag som inneholder endringer i secret chats-implementeringen (f. eks. du trenger ikke å gjøre dette når klienten oppdateres Fra Lag 46 Til Lag 47).
