Frontpage

Meta Vault

2 versioner, en krypterad, en krypterad.

(använd timestamp för all data, inte time-bucket)

Version 1

Ej krypterad.

Meta Vault, tidigare version

Tänk ett kassaskåp för metainformation. Själva utgångspunkten för klientens interaktion med server.

Detta rör klientens inloggning och data-tillgång.

Beslut

När klienten skapar ett konto sker det i två steg

Steg 0

Klienten, besöker matkalkyl.se via webbläsare, erhåller JavaScript kod (själva matkalkyl-programmet) som körs i klientens webbläsare.

Steg 1 - nytt konto

I detta steg har klienten ingen kontakt med webservern. Allt i steg 1 körs på klientens enhet.

Klienten:

  • väljer lösenord (P) (kan välja användarnamn med, men är inte basalt). Generera nyckel (DK) baserat i lösenordet (P), "Derived Key", enligt standard (ex. PBKDF2).
  • genererar en krypteringsnyckel enligt standard (EK) som används för att kryptera data.
  • genererar nonce (N) (unik sekvens med karaktärer, används senare för autentifikation).
  • genererar en siffra för nuvarande period (TB - time bucket) (servern lagrar inte senaste inloggning-tid, enbart huruvida användaren loggat in den senaste perioden. En period är X år. Detta för att kunna radera gammal data hos icke återvändande användare.)

Sätt ihop allt till ett paket (MV - Meta Vault):

{
  "encryption_key": "EK",
  "nonce": "N",
  "time-bucket": "TB",

}

Kryptera MV med DK, och vi får EMV (Encrypted Meta Vault).

Klienten genererar ett UUIDv7, ett nummer mellan 0 och 340,282,366,920,938,463,463,374,607,431,768,211,455.

UUID som genereras används för den data klienten vill lagra (DBID - data block ID)

Det är 340.3 quintillioner. Det beräknas finnas 7.5 quintillioner sandkorn på jorden. Vi är i praktiken garanterade att få ett unikt UUID. Det är därför klienten själv kan generera id utan serverns inblandning.

Klienten skickar DBID+EMV till servern. Servern lagrar det som så.