This document describes the hdrop security model in detail.
hdrop exclusively uses WebCrypto
APIs provided by the browser for all cryptographic operations.
- Generate a random salt
S
with a size of 16 bytes - Derive a key
K
from the passwordP
using600_000
rounds ofPBKDF2(P, S)
- Generate a random initialization vector
IV
with a size of 12 bytes- The frontend provides two static XOR masks to generate different IVs for the file name and the challenge (based on the random IV).1
- Producing IV, Name_IV, Challenge_IV
- Encrypt file data
Fd
usingAES-256-GCM-ENC(IV, K, Fd)
- Producing encrypted file data
EFd
- Producing encrypted file data
- Encrypt file name
Fn
usingAES-256-GCM-ENC(Name_IV, K, Fn)
- Producing encrypted file name
EFn
- Producing encrypted file name
- Generate and encrypt 32 bytes long file challenge
Fc
usingAES-256-GCM-ENC(Challenge_IV, K, Fc)
- Producing encrypted file challenge
EFc
- Producing encrypted file challenge
- Hash file challenge
Fc
usingSHA-256(Fc)
- Producing hashed file challenge
H(Fc)
- Producing hashed file challenge
- Upload data to the server:
- Encrypted file contents
- Base64-encoded encrypted file name
- Base64-encoded salt
- Base64-encoded IV
- Base64-encoded encrypted challenge data
- Hashed challenge data
- Get a pair of tokens back:
- Access Token
Ta
(guaranteed unique) - Update Token
Tu
(not unique, but sufficiently random)
- Access Token
Token | Private | Usage |
---|---|---|
Access Token Ta |
no |
Used for file retrival by third parties |
Update Token Tu |
yes |
Used for authenticating the original uploader |
Update expiry and manual deletion can only be done by the owner (original uploader).
Expiry time is recalculated based on original storage date.
The Update TokenTu
is used to authenticate the caller.
The Update Token
Tu
is used to authenticate the caller.
- Retrieve challenge data (
EFn
,S
,IV
) from server - Derive a key
K
from the passwordP
using600_000
rounds ofPBKDF2(P, S)
- Decrypt the encrypted file challenge
EFc
usingAES-256-GCM-DEC(Challenge_IV, K, EFc)
- Producing file challenge
Fc'
(==Fc
, if successful)
- Producing file challenge
- Hash file challenge
Fc'
usingSHA-256(Fc')
- Producing challenge solution
H(Fc')
(==H(Fc)
, if successful)
- Producing challenge solution
- Send challenge solution
H(Fc')
to server
- Check challenge solution
H(Fc')
against hashed file challengeH(Fc)
IF H(Fc') == H(Fc)
: Challenge solved, respond with success and encrypted file nameEFn
IF H(Fc') ≠ H(Fc)
: Challenge failed, respond with error and deny download
The challenge solution
H(Fc')
acts as an authorization bearer token for the download
- Decrypt encrypted file data
EFd
usingAES-256-GCM-DEC(IV, K, EFd)
- Producing file data
Fd
- Producing file data
- Decrypt encrypted file name
EFn
usingAES-256-GCM-DEC(Name_IV, K, EFn)
- Producing file name
Fn
- Producing file name
The client can - given the right access token - always request the encrypted file challenge. The challenge is mainly a solution to improve UX by avoiding having to download the entirety of encrypted file contents before attempting decryption. It also has the added benefit of completely denying access to the encrypted file data and name for people without the right password.
Footnotes
-
The GCM mode of operation should never reuse the same IV to encrypt other related data/messages. Therefore two XOR masks are provided instead of generating three different IVs. This ensures 100% that the IVs for data, name and challenge are all different. The XOR masks are located in the frontend to avoid storing two additional rows for the IVs in the backend database. ↩