Portal | Khaopiak

Download files

Partially implemented

This form will only download the file from Khaopiak and not decrypt it if client-side encryption was involved in its upload.

Purpose

Khaopiak is a temporary, intermediary file storage system for transferring between two devices. It was designed primarily with printing at hotel business centers in mind, but can cover a range of use cases from file transfers, viewership verification, and sharing secrets.

🖨️ Use Case: Printing at hotel business centers

Hotel business centers often restrict printing to dedicated, shared desktops, resulting in two main options for printing from a personal device:

Connect personal hardware (ex. USB thumb drives) to shared equipment
Upload files to a web-based intermediary for download

Personal hardware

Connecting personal hardware may not always be an option, whether due to port restrictions (such as software restrictions and the lack of a physical port) or the lack of a physical medium (i.e. cabling or drives). Shared devices may also harbor malware, stealing files and potentially infecting connected devices.

Web-based portals

Logging into web-based portals such as Google Drive, Box, SharePoint, Proton Drive, and Dropbox requires inputting personal login credentials and grants excessive access to files alongside additional services, such as email. When passwords are shared, stolen credentials may lead to further compromise, such as enabling logon to financial accounts. While these web-based services often provide shareable links, they are often too long or complicated to type, such as this Google Drive share link:

https://docs.google.com/document/d/t9trB8lKoaB_kIRk6FeFltqm1TGdsCpKolHGwcpVKXPE

When end-users incorrectly type a character of these URLs, it is often difficult to identify the source of error. To mitigate this issue, a link shortener can be used; however, it increases the probability of randomly stumbling upon the document, involves an additional party, and may be predictable. Shareable links often do not expire, allowing a threat actor to regain access after the initial download, such as through browser history.

How Khaopiak helps

Khaopiak alleviates these issues through enabling the seamless end-to-end encryption of documents accessed through easily-typed, one-time-use BIP39 mnemonics, such as:

orchard home picture movie only what believe onion physical defy hole among climb brand million edge anchor upgrade sand awake loop layer panther soda

This means that end-users need not reference a random character-by-character string, but known words they can quickly type and remember the spelling of. As all words can be identified using their first three letters, Khaopiak can automatically correct typos. During this process, hardware manipulation is not required, users do not need to enter logon credentials besides a unique, expiring mnemonic, and mnemonics cannot be reused to download the same upload.

🤝 Use Case: Secrets distribution

Khaopiak can be used to share secrets in an environment where communications integrity is guaranteed; however, confidentiality is susceptible to compromise, such as communicating vocally in an open office, on the condition that the secret is not of value immediate value. This leverages Khaopiak's expiring mnemonics, thus if the intended receiver successfully downloads from the Khaopiak server, it can be assumed that only they have it. The receiver can then communicate back to the sender to confirm receipt and use the secret. If the secret for transmission is of immediate value, two Khaopiak uploads can be used for secure transmission. First, transmitting a secret of no immediate value: the client-side mnemonic for an intended upcoming transmission. If receipt is confirmed by the intended recipient, that client-side mnemonic can then be used to encrypt the actual secret client-side for upload to Khaopiak.

✅ Use Case: Confirmed file access

Expiring mnemonics enables confirmed file access through using the Khaopiak server's file existance checking. If Khaopiak reports that a file exists, it has not yet been downloaded. If it reports that a file does not exist, it implies that the file has already been downloaded or the file expired.

Features

For end users

🔒 End-to-end encryption

A portion of the mnemonic is never transmitted over the internet and is used to encrypt the file before uploading, allowing end-to-end encryption. As a result, confidentiality of the original file is protected as it is never made available to intermediaries. For all purposes of encryption, Khaopiak uses the Advanced Encryption Standard (AES), with all clients supporting Cipher Block Chaining (CBC) (https://csrc.nist.gov/pubs/sp/800/38/a/final) and recommending Galois/Counter Mode (GCM) (https://csrc.nist.gov/pubs/sp/800/38/d/final) when possible.

⌛ Expiring files

By default, all files uploaded to Khaopiak eventually expire. If an attempt is made to an expired file which has not been deleted from the Khaopiak server, it will be immediately deleted and a response will be returned as if the file did not exist. Note: It is possible for a client to assume that a file existed based on the additional processing time required to check whether the file expired.

🗄️ Protected file metadata

File names and content types are included as part of the payload for encryption at both the client and server sides. As a result, at rest, file content cannot be easily inferred.

📏 Configure mnemonic lengths

Mnemonics can range from 24 to 48 words where end-users can specify the amount of words for the client and server independently. As a result, users can choose to increase encryption key lengths for more sensitive files for increased assurance that data confidentiality is protected.

For administrators

🔑 Restrict access with Cloudflare Access

Cloudflare Zero Trust customers can optionally require authentication through Cloudflare Access as a self-hosted application. Khaopiak will check for a cf-access-authenticated-user-email header containing a valid email. Cloudflare prevents impersonating through stripping the header from client requests.

☁️ Serverless deployment

Khaopiak is designed for deployment on Cloudflare Workers (https://workers.cloudflare.com/), leveraging Cloudflare R2 (https://developers.cloudflare.com/r2/) for file storage and Cloudflare Queues (https://developers.cloudflare.com/queues/) for file expiry, allowing deployment and automated scaling without having to maintain servers.

For all

📖 Open source

Unlike commercially available products, Khaopiak is open source. Organizations and end-users need not go solely based on product claims, but verify them through analyzing both code and infrastructure design. If a provider hosting a Khaopiak server cannot be trusted, a private instance can quickly be deployed.

Security considerations

🔐 Cryptographic strength of encryption algorithms

Khaopiak supports AES-CBC and AES-GCM as they are available through the SubtleCrypto interface of the Web Crypto API (https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto):

RSA-OAEP is not supported as it is a public-key encryption system, where current guidelines recommend a minimum of 2048 key bits. To meet this, 192+ BIP39 words would be required, which is unreasonable for an end-user. While client developers may use it for client-side encryption, server-side mnemonic-based encryption/decryption with RSA-OAEP will not be offered.
AES-CTR is not supported as it is malleable, potentially allowing the meaning of the ciphertext to be changed.
AES-CBC is supported as a client-side encryption algorithm. While Khaopiak is generally not itself vulnerable to a padding oracle attack, client developers should be aware of the algorithm's vulnerability.
AES-GCM is supported as both a client and server-side encryption algorithm. AES-GCM provides authenticated encryption which helps authenticate the ciphertext. Additional design considerations are necessary when it is possible for a key and initialization vector (IV) may potentially be reused; however, Khaopiak generates a random key and IV for each upload.

The OpenSSL enc program does not support authenticated encryption modes. As a result, some clients may use AES-CBC instead, such as uploading from the command line.

💥 Server-side collisions

Khaopiak does not generate guaranteed unique mnemonics. As a result, it is theoretically possible for a collision to occur, which may enable accidental file overwriting or downloading of an alternate file. However, this case is extremely improbable. Client-side encryption helps protect data confidentiality even in the presence of a server-side failure. While it is possible for another collision, enabling decryption of the file, this is improbable.

🦹 Mnemonic theft

To conveniently use Khaopiak, the same portal should both accept a server mnemonic and a client mnemonic. However, the client mnemonic could accidentally be sent to the server if entered incorrectly, compromising end-to-end encryption. A portal may also be maliciously designed to explicitly capture client mnemonics. To avoid mnemonic theft, an end-user should have a means of verifying the portal's legitimacy (such as through TLS certificates). Further, the portal should have a clear means of distinguishing the client and server mnemonics, such as using half of a combined mnemonic for each, or using a distinct wordlist for the client and server.

🧮 User-specified entropy length

When a user specifies an entropy length of 160 or 224, Khaopiak pads the entropy to become 192 or 256 bits, respectively, as AES only supports 128, 192, and 256-bit keys. As a result, while a longer-bit algorithm is used for encryption, it does not inherently increase the level of security assurance as the padding is predictable.

For more about Khaopiak, please visit the project's GitHub repository (https://github.com/Jayson-Fong/Khaopiak).

🍜 Khaopiak

Upload files