Paano maiimbak at masi-synchronize ng isang server ang aming mga lihim nang hindi hinahawakan ang mga susi upang basahin ang mga ito? Susundan namin kung paano nililikha ng Confidex ang mga susi nito, pinoprotektahan ang mga ito sa isang lock at ginagamit ang mga ito upang i-encrypt ang data at i-verify ang mga pagbabago.

Kandado

Ang Hinirang lamang ang makapagbubukas ng pinto

Na-reload ang Matrix

Isipin na gumagawa kami ng virtual vault upang mag-imbak ng lihim na data. Dapat itong panatilihin ang data na iyon sa isang laptop pagkatapos magsara ng application at hayaan kaming buksan ito sa isa pang device. Kakailanganin ng vault ang sarili nitong mga susi. Dapat nating iimbak ang mga ito upang ang pagkopya ng mga file ay nagbibigay sa isang tagalabas na walang paraan upang basahin o baguhin ang kanilang mga nilalaman.

Pinoprotektahan ng lock ang mga susi: isang maliit na naka-encrypt na file. Ang pagbubukas nito ay nangangailangan ng master password at isang lihim na code, secret_key; wala sa file mismo. Maaari naming i-print ang buong lock sa pahayagan sa umaga. Makakakuha ng kopya ang mga mambabasa, ngunit ang pag-publish nito ay hindi magbubunyag ng mga pribadong key.

Ipagpalagay na ang isang tagalabas ay nakakuha ng file na ito at natutunan pa ang master password. Maaari na nilang ulitin ang bawat pagkalkula na nangangailangan lamang ng password, ngunit ang mga kalkulasyong iyon ay hindi maglalabas ng susi na magbubukas ng lock: secret_key ay isa ring input. Ang file ay naglalaman ng walang hiwalay na pagsusuri ng password lamang. Ang pagbubukas nito ay nangangailangan pa rin ng hindi kilalang sikretong code.

Ang code na iyon ay mula sa cryptographically random na data; hindi ito iniimbento ng isang tao. Hangga't hindi alam ang secret_key, kahit na ang master password na nahulaan nang tama ay hindi magbubukas ng lock: kulang pa rin ang umaatake ng random na lihim. Ang isang mahinang password lamang samakatuwid ay hindi ginagawa ang kopya ng server sa isang praktikal na pag-atake sa diksyunaryo.

Kung nakakuha din ang attacker ng secret_key, maaari nilang subukan ang mga hula sa master-password offline. Ito ay magastos, ngunit ang kahirapan sa wakas ay nakasalalay sa lakas ng password.

Mga susi

Mga ginoo, ano ang ginagawa ng mga susi? Mga susi... i-unlock ang mga bagay?

Pirates of the Caribbean – Dibdib ng Patay na Tao

Ang application ay nakakakuha ng 32 random byte mula sa cryptographic generator ng operating system at inihahanda ang mga ito para magamit bilang isang susi. Ang mga inihandang byte na ito ay ang pribadong master key, master_key.

Palaging nakukuha ng application ang parehong mga key mula sa master_key: ang pag-uulit ng parehong mga kalkulasyon sa parehong mga byte ay nagbibigay ng parehong resulta. Ang isang laptop at isang telepono ay maaaring mabawi ang magkaparehong mga susi. Upang makakuha ng master_key sa isang bagong device, dapat munang buksan ng application ang lock gamit ang master password at secret_key.

Ang unang pares: encryption

Ako ang Keymaster.

Ghostbusters

Upang mag-imbak ng naka-encrypt na data, kinukuwenta ng application ang isang pampublikong key mula sa master_key: secret_key. Maaari itong mag-encrypt ng data para sa vault, habang ang pag-decryption ay nangangailangan ng master_key.

Inilalarawan ng "Pampubliko" ang papel ng key na ito sa algorithm, hindi isang obligasyon na ibigay ito sa lahat. Sa Confidex mananatili ito sa user. Ito rin ang pangalawang lihim na kailangan upang buksan ang lock, kaya nananatili itong lokal at hindi ipinadala sa network. Sa sarili nitong paraan, hinahayaan ng secret_key ang isang tao na mag-encrypt ng data para sa vault, ngunit hindi ito i-decrypt o pumirma ng mga pagbabago sa ngalan nito.

Ang X25519 ay ang algorithm na kumukuha ng master_key at kumukwenta ng secret_key. Ang pagbawi ng master_key mula sa secret_key ay halos hindi magagawa. Ang isang klasikal na pag-atake sa isang haka-haka na supercomputer na nagsasagawa ng isang bilyong bilyong pagpapatakbo ng curve bawat segundo ay aabutin ng humigit-kumulang 2.3 trilyong taon sa average (SafeCurves estimate).

Ang pangalawang pares: mga lagda

Ang tanging orihinal ay ang lagda

Abangan Mo Kung Kaya Mo

Ang unang pares ay tumutulong na itago ang mga nilalaman. Kailangan namin ngayon ng paraan para kumpirmahin na pinahintulutan ng may-ari ng vault ang pagbabago. Dapat na masuri din ng server ang mga lagda, kaya kailangan namin itong ipadala sa isang pampublikong verification key. Ang pampublikong bahagi ng unang pares ay secret_key, na hindi dapat matanggap ng server. Samakatuwid, lumikha kami ng pangalawang, permanenteng key pair para sa mga lagda.

Sa halip na mag-imbak ng isa pang independiyenteng lihim, kumukuha kami ng pribadong signing key mula sa master_key at tinatawag itong signing_key. Ginagamit ito ng application para lagdaan ang data at ang lock. Ginagamit ng ibang mga device at ng server ang pampublikong bahagi nito upang suriin ang mga lagda nang hindi binabasa ang mga nilalaman.

Mababawi namin ang pares na ito mula sa parehong master_key. Ang application ay nakakakuha ng panimulang halaga mula dito: 32 byte na natatanging tumutukoy sa signing key.

Upang makakuha ng iba't ibang key para sa iba't ibang trabaho, nagsasama kami ng nakapirming label sa pagkalkula: dito, confidex/vault/ed25519/v1. Ang parehong master_key at ang parehong label ay palaging gumagawa ng parehong key.

Hindi naipasok ng master password ang mga kalkulasyong ito. Ang parehong mga pares ay nakadepende sa mga random na byte ng master_key, hindi sa isang string na naimbento ng isang tao. Ang pagkakaibang ito ay magiging mahalaga sa ibang pagkakataon: ang password ay magpoprotekta sa pag-access sa mga susi na mayroon na, upang maaari naming baguhin ito nang hindi binabago ang mga susi mismo.

Gumagamit ang derivation ng hash-based na key derivation function: HKDF, HMAC-based Extract-and-Expand Key Derivation Function. Ginagamit ito ng Confidex kasama ng SHA-256, kaya tinawag itong HKDF-SHA256. Ang nagreresultang 32 byte ay ang seed para sa Ed25519 pares. Ang pampublikong bahagi ng signing_key ay hindi naghahayag ng secret_key, kaya maaari naming ipadala ito sa server para sa pag-verify ng lagda.

Ano ang lock file, at ano ang ginagawa nito?

Buksan ang mga pinto ng pod bay, HAL.
I'm sorry, Dave. Natatakot akong hindi ko magawa iyon.

Isang Space Odyssey

Ang lock ay nag-iimbak ng naka-encrypt na master_key. Ang pagbubukas nito ay nangangailangan ng master password at secret_key. Ang pampublikong header ay naglalaman ng bersyon ng format, ang vault identifier, ang pampublikong bahagi ng signing_key, asin at ang mga parameter sa pagproseso ng password. Ang bersyon ng panloob na format ay naka-encrypt kasama ng master_key.

Kapag gumagawa ng lock, mayroon nang master_key ang application, kaya kinukuwenta nito ang secret_key bago ang pag-encrypt. Kapag binubuksan ito, ibinibigay ng user ang secret_key nang hiwalay: wala ito sa pampublikong kopya ng lock.

Pagkatapos ng pag-decryption, kino-compute ng application ang pampublikong bahagi ng master_key gamit ang X25519 at kailangan itong tumugma sa secret_key. Pagkatapos ay binabawi nito ang signing_key at ikinukumpara ang pampublikong bahagi nito sa susi sa header. Sa ganitong paraan, sinusuri ng lock ang sarili nito.

Upang mapabagal ang paghula ng master-password, ang bawat pagtatangka ay kailangang maglaan ng oras at memorya. Gumagamit ang Confidex ng Argon2id na may 64 MiB ng memory at tatlong pass. Gumagamit din ang pagpoproseso ng password ng random na asin. Ang asin ay hindi lihim: ito ay gumagawa ng parehong password na makagawa ng iba't ibang mga resulta sa iba't ibang mga kandado.

Kung alam na ang secret_key, kapansin-pansing binabago ng haba ng password ang sukat ng isang pag-atake. Mayroong humigit-kumulang 12 milyong kumbinasyon ng 5 random na maliliit na letrang Latin, humigit-kumulang 8 bilyon ng 7, at humigit-kumulang 95 quadrillion ng 12. Ang pagpunta mula 7 hanggang 12 titik ay nagpapataas ng espasyo sa paghahanap ng halos 12 milyong beses. Kung ang paghahanap ng 7 titik ay tumagal ng isang araw sa average sa isang partikular na makina, 5 ay aabot ng humigit-kumulang dalawang minuto, at 12 ay humigit-kumulang 33,000 taon.

Upang makakuha ng isang key mula sa resulta ng Argon2id at secret_key, ginagamit namin ang function na HKDF-SHA256 na ipinakilala kanina, na may label na confidex/lock/wrap/v1. Ang resulta ay wrapping_key, ang susi na nag-e-encrypt sa lock.

Dapat nating itago ang master_key at protektahan ito mula sa pakikialam. Ini-encrypt ito ng XChaCha20-Poly1305 gamit ang wrapping_key at nagdaragdag ng tag ng pagpapatunay. Ang tag ay nagbubuklod sa ciphertext sa pampublikong header: ang isang maling password o isang pagbabago sa mga protektadong byte ay nagpapabagsak sa pagbubukas. Ang tag at isang random na single-use value, ang nonce, ay naka-store kasama ng ciphertext.

Sa tuwing gagawin o mai-encrypt muli ang lock, nakakakuha ang application ng sariwang asin at nonce. Kasama sa mga naka-encrypt na nilalaman ang isang byte na bersyon at ang 32 byte ng master_key; isang 24-byte nonce at isang 16-byte na tag ang naka-store sa tabi nila. Inilalarawan ng dokumentasyon ng algorithm ang pagbuo.

Ang isang hindi pagkakatugma sa pagitan ng mga na-recover na key ay maaaring magresulta mula sa isang sadyang malform na lock o isang bug sa program na lumikha nito. Ang random na byte na katiwalian ay karaniwang nakikita nang mas maaga, kapag ang tag ay nasuri.

Ang server ay walang mga lihim na kailangan upang suriin ang tag na ito. Upang ilipat ang lock, ang application samakatuwid ay nagdaragdag ng isang lagda na ginawa gamit ang signing_key. Sinasaklaw nito ang buong natapos na file, kabilang ang pampublikong header at mga naka-encrypt na nilalaman. Sinusuri ng server ang lagda at, sa unang pag-upload, ipi-pin ang buong pampublikong bahagi ng signing_key at ang panloob na identifier ng vault. Sinusuri nito ang mga kasunod na pagbabago laban sa key na ito. Ang lock at naka-encrypt na data ay nilagdaan ng parehong signing_key, na na-recover mula sa master_key.

Ang vault

Maaari na nating i-publish ang lock. Tanging isang taong nakakaalam ng secret_key at ang master password ang makakabasa ng master_key, habang sinuman ang maaaring kumuha ng pampublikong signing key mula sa lock file at suriin ang nilagdaang data nang hindi nakikita ang mga nilalaman ng alinman sa lock o data.

Isaalang-alang ang isang password, SuperPa55worD. Sa ngayon, gusto lang namin itong i-save: pagkatapos isara ang application, dapat naming maipadala ang lock file at ang naka-encrypt na password kahit saan nang walang sinumang nakakakita ng SuperPa55worD, habang hinahayaan pa rin silang i-verify ang aming pagiging may-akda. Dapat na maibabalik ang pag-encrypt kapag mayroon kaming secret_key at ang master password. Ang isang simetriko cipher ay maaaring mag-encrypt at mag-decrypt gamit ang parehong key. Dahil hindi namin iniimbak ang susi na iyon, dapat naming mabawi ito gamit ang lock. Tatawagin namin itong message_key.

Makakakuha kami ng hiwalay na message_key para sa bawat bagong pag-encrypt. Kailangan pa rin nating ayusin ang pagbawi nito: ang pag-iwan sa susi sa bukas sa tabi ng ciphertext ay hahayaan ang sinumang may kopya na basahin ang lahat.

Mula sa mga sariwang random na byte, lumilikha ang application ng pansamantalang X25519 pares para lang sa pag-encrypt na ito: record_key. Pagkatapos ay kukunin nito ang pribadong bahagi ng record_key at ang permanenteng pampublikong key ng vault, secret_key, at kinukuwenta ang isang nakabahaging lihim. Nakukuha ng hiwalay na function ang message_key mula sa lihim na iyon; ine-encrypt ng key na ito ang aming password.

Kapag nagbabasa, ang application ay tumatagal ng isa pang ruta. Gumagamit ito ng master_key at ang pampublikong bahagi ng record_key. Ang dalawang key na ito ay gumagawa ng parehong ibinahaging lihim. Sa matematika, ang parehong mga ruta ay nagpaparami ng parehong paunang punto sa curve sa pamamagitan ng dalawang pribadong numero, sa ibang pagkakasunud-sunod. Hindi binabago ng order ang resulta. Kaya't maaari naming mabawi ang decryption key nang hindi pinapanatili ang pribadong bahagi ng record_key.

Ang pagkuha ng lihim na ito mula sa dalawang pampublikong susi ay halos imposible: ang alinmang ruta ay nangangailangan ng kaukulang pribadong susi. Ang mga pampublikong punto ay hindi nagpapahintulot sa amin na mahusay na mabawi ang mga pribadong numero na gumawa ng mga ito. Ang mathematical trick na ito ay nagpapatibay sa seguridad ng vault. Ngunit hindi nito pinipigilan ang isang tao na magbigay sa amin ng ibang vault na ang aming lock ay nakakabit dito.

Maaari na nating iimbak ang ciphertext sa tabi ng pampublikong bahagi ng record_key. Ang pribadong bahagi ng record_key at ang ginamit na message_key ay hindi na kailangan para sa pagbabasa sa hinaharap. Sa paglaon, na-recover ng application ang decryption key mula sa master_key at ang nakaimbak na pampublikong bahagi ng record_key. Ang isang permanenteng vault secret ay maaaring mag-decrypt ng maraming hiwalay na naka-encrypt na halaga, bawat isa ay may sariling message_key na mababawi kapag kinakailangan.

Hindi sapat ang pagtatago ng text: dapat din nating makita ang pakikialam kapag binabasa ito. Ang pag-encrypt samakatuwid ay nagdaragdag ng isang authentication tag, isang maikling halaga na sinuri kasama ng naka-encrypt na data. Kung nabigo ang tseke, tinatanggihan ng aplikasyon ang resulta. Hindi ito dapat magpakita ng random o binagong teksto bilang isang matagumpay na na-decrypt na password.

Inilarawan namin ang isang konstruksyon kung saan nakakatulong ang isang pares na walang simetriko na magtatag ng isang nakabahaging lihim, habang ini-encrypt ng message_key ang mga nilalaman. Ito ay tinatawag na Hybrid Public Key Encryption, o HPKE, at tinukoy sa RFC 9180. Gumagamit ang Confidex ng X25519 upang sumang-ayon sa sikreto, HKDF-SHA256 upang makuha ang mga susi, at ChaCha20-Poly1305 para sa pag-encrypt na may pagsusuri sa integridad. Dito, kinukuha ng HKDF ang nakabahaging lihim na napagkasunduan gamit ang record_key at ang master_key na pares; ito ay isang hiwalay na trabaho mula sa pagkuha ng Ed25519 seed. Inilalarawan ng RFC 5869 ang HKDF.

Para sa susunod na pag-encrypt, gagawa ang application ng bagong record_key at bagong HPKE na konteksto. Ang muling paggamit ng kumbinasyon ng message_key at nonce ay sumisira sa proteksyon ng cipher. Sa Confidex, ang susi at nonce ay hinango sa loob ng HPKE, ginagamit para sa isang mensahe, at pagkatapos ay itatapon ang konteksto.

Ang ChaCha20 mismo ay gumagamit ng 256-bit message_key. Upang magkaroon ng pakiramdam ng isang direktang pag-atake, isipin ang isang kathang-isip na supercomputer na sumusubok sa 10¹⁸ posibleng key bawat segundo. Ang paghahanap sa 2²⁵⁶ na posibleng mga key ay aabot ng humigit-kumulang 1.8 × 10⁵¹ taon. Inilalarawan ng RFC 8439 ang algorithm at ang pagsusuri nito.

Isang record

Masaya kami?

Pulp Fiction

Nai-save namin ang password, ngunit ang pag-log in sa isang website ay karaniwang nangangailangan din ng isang username at isang address. Minsan kailangan natin ng note sa tabi nila. Kung iimbak namin ang mga halagang ito nang hiwalay, dapat tandaan ng application na magkakasama ang mga ito. Ilagay natin ang mga "papel" na ito sa isang sobre. Pinagsasama namin ang mga field sa isang koleksyon at tinatawag itong record.

Ang isang talaan ay maaaring maglaman ng anumang kumbinasyon ng mga patlang. Pinagsasama-sama ng application ang mga ito sa isang packet, pini-compress ito at ini-encrypt ang kabuuan gamit ang konstruksiyon na inilarawan namin. Ang mga halaga ng field, pangalan, uri at tag ay protektado lahat. Ang pagpapalit ng address ng website, kahit na pinapanatili ang parehong password, ay lumilikha ng bagong bersyon ng buong record, na naka-encrypt gamit ang bagong record_key.

Hash-chain

DAPAT BA ANG IYONG PROYEKTO GUMAMIT NG BLOCKCHAIN? → HINDI

XKCD 2267

Maaaring maghanda ang isang taong nakakaalam ng secret_key ng naka-encrypt na tala para sa aming vault. Upang maiwasang tanggapin ito bilang atin, nilalagdaan ng application ang bawat bersyon ng record gamit ang signing_key. Kung wala ang key na ito, hindi makakagawa ang isang tagalabas ng bersyon na may lagda na tatanggapin ng server at iba pang device.

Ang naka-encrypt na bersyon ay nangangailangan ng ilang kasamang impormasyon: kung saang vault at record ito kabilang, kapag ito ay nagbago, at kung aling mga bersyon ang nauuna dito. Ito ang bumubuo sa pampublikong header. Hindi ito naglalaman ng password, ngunit nangangailangan pa rin ito ng proteksyon: kung hindi, maaaring baguhin ng isang tao ang pagmamay-ari at relasyon ng mga bagay nang hindi hinahawakan ang ciphertext. Pinirmahan ng application ang eksaktong mga byte ng header kasama ang ciphertext. Ang pagpapalit ng nilagdaang data ay magpapawalang-bisa sa lagda.

Ang server ay kahawig ng isang bodega ng mga selyadong parsela. Nakikita nito ang header, mga naka-encrypt na nilalaman at lagda, ngunit hindi ang password sa loob, at alam nito na ang tatanggap ay umiiral sa lungsod. Sinusuri nito ang lagda laban sa naka-pin na pampublikong bahagi ng signing_key at nagpapasya kung tatanggapin ang bagong bersyon. Hindi nito kailangan ang master password o secret_key o anumang pribadong key. Kapag nagbabasa, sinusuri ng kliyente ang parehong pirma, pagkatapos ay susuriin muli ang pagbubuklod sa pagitan ng mga nilalaman at ng header sa panahon ng pag-decryption, gamit ang tag ng pagpapatunay ng HPKE.

Pinoprotektahan din ng lagda ang mga link sa pagitan ng mga bersyon. Ang isang SHA-256 hash ng eksaktong header at ciphertext byte ang nagiging identifier ng bersyon. Ang header ng susunod na bersyon ay naglalaman ng identifier ng nakaraang bersyon. Kapag binago namin ang password ng website, gagawa at pumirma ang application ng bagong object gamit ang link na ito. Ang lumang bagay at ang lagda nito ay nananatiling hindi nagbabago. Ang pagpapalit ng hinalinhan habang pinapanatili ang lagda ng bagong bersyon ay mabibigo. Kung ang dalawang aparato ay gumawa ng mga independiyenteng pagbabago, ang parehong mga sangay ay mabubuhay; ang isang pinagsamang bersyon ay maaaring sumangguni sa pareho.

Tandaan ang blockchain? Ayan na :-).

Hinahayaan kami ng pampublikong header na suriin ang mga link nang hindi nagde-decrypt, ngunit nananatiling nakikita ang ilang impormasyon. Alam ng server ang mga identifier, mga link ng bersyon, ang oras ng pagbabago na ibinigay ng kliyente, ang bilang ng mga field, at ang laki ng naka-encode na halaga ng bawat field. Itinatago ng pag-encrypt ang mga nilalaman ng rekord, hindi ang impormasyong ito sa istruktura.

Sync

“Hindi isang data leak, isang libreng ibinahagi na backup.”

Internet meme.

Para gumana sa ilang device, kailangan naming ilipat ang lock at i-record ang history sa pagitan ng mga ito. Hindi nagbabago ang format ng object: inililipat namin ang parehong naka-encrypt na byte at mga lagda na lokal na nakaimbak.

Para sa manu-manong paglipat, gagawa ang application ng ZIP archive na naglalaman ng lock, lahat ng lokal na naka-imbak na naka-encrypt na bersyon ng talaan, at isang nilagdaang listahan ng file. Hindi kasama ang password o secret_key. Sa isa pang device, bubuksan muna ng application ang lock, pagkatapos ay susuriin ang mga lagda, i-decrypt ang mga talaan at ire-restore ang isang lokal na kopya ng vault. Ang pag-import ay inilaan para sa isang device kung saan wala pa ang vault na ito; hindi nito pinagsasama ang kasaysayan sa isang umiiral nang kopya.

Ang isang sync server ay nagpapalitan ng mga pagbabago sa pagitan ng gumaganang mga kopya. Sa unang pag-upload, natatanggap nito ang nilagdaang lock, sinusuri ang pirma at kinukuwenta ang pampublikong address ng vault mula sa pampublikong bahagi ng signing_key. Naaalala nito ang key na ito at ang vault identifier mula sa header: nirerehistro nito ang vault sa server. Ang mga kasunod na pagbabago ay dapat tumugma sa identifier na ito at may pirma mula sa parehong key.

Kailangan ng bagong device ang address ng vault at secret_key, kaya pinagsama-sama ng application ang mga ito sa isang transfer code na may checksum. Inilipat ng user ang code na ito sa device at hiwalay na ipinasok ang master password; tanging ang pampublikong address ang ipinadala sa server.

Pagkatapos buksan ang na-download na lock, ikinukumpara ng application ang mga pampublikong bahagi ng mga na-recover na key sa secret_key at sa header, at sinusuri ang nakalkulang address laban sa transfer code. Pagkatapos ay sine-save nito ang na-verify na pampublikong bahagi ng signing_key upang suriin ang mga talaan.

Sa panahon ng pag-synchronize, kinukuha ng application ang mga nawawalang bersyon at ina-upload ang mga pagbabago nito. Sinusuri ng server ang mga lagda at mga link sa mga naunang bersyon, nag-iimbak ng mga tinanggap na bagay at ipinapasa ang mga ito sa iba pang mga device. Ang pagsuri sa natanggap na data, pag-decryption nito at paglutas ng mga salungatan ay nangyayari lahat sa mga device ng user.

Ang pagpaparehistro ay hindi humihingi ng pangalan, email address o hiwalay na password. Nakikita ng server ang pampublikong address, signature verification key, mga pampublikong header, laki ng object at mga link ng bersyon. Nakikita rin nito ang mga IP address at mga oras ng paghiling. Mananatili sa mga device ng user ang master password, secret_key, mga pribadong key at mga nilalaman ng plaintext record. Maaaring i-download ng sinumang nakakaalam ng pampublikong address ang mga naka-encrypt na bagay, ngunit ang pagbabasa ng mga ito ay nangangailangan ng mga lihim ng user.

Nakikita ng mga pagsusuring ito ang mga huwad na bagay, ngunit hindi nagpapatunay na ipinakita ng server ang kumpletong kasaysayan at ang pinakabagong estado nito. Maaari nitong itago ang isang sangay na hindi pa nakita ng kliyente o ibalik ang isang pare-parehong mas lumang dataset. Kinukumpirma ng isang lagda ang pagiging tunay ng isang indibidwal na bagay, hindi ang pagkakumpleto ng tugon ng server. Maaaring mapansin ng user ang mga nawawalang pagbabago sa isa pang device, ngunit ang isang pare-parehong lumang kasaysayan ay papasa sa hash-chain pag-verify.

Pagbabago ng master password

Kaya, gusto ba ng iyong kabanalan na baguhin ang kanyang password?

Mga Hacker (1995)

Ang pagpapalit ng master password ay muling ine-encrypt lamang ang lock; master_key sa loob ay nananatiling pareho. Ang mga tala, kanilang mga lagda, secret_key at ang address ng vault samakatuwid ay nananatiling hindi nagbabago. Ang bagong lock ay nilagdaan ng parehong signing_key.

Magbubukas pa rin ang isang lumang kopya ng lock gamit ang lumang password at ang parehong secret_key; hindi binabawi ng pagbabago ng password ang mga key na nalantad na.

Ang buong larawan

Pinoprotektahan ng lock ang master_key, message_key ang nag-e-encrypt ng mga tala, at ang signing_key ay gumagawa ng mga lagda. ZIP na mga archive at ang server ay tumatanggap ng mga naka-encrypt na bagay na may mga lagda.