Update readme

README.md

@@ -0,0 +1,112 @@
+# OmegaUpload
+
+OmegaUpload is a zero-knowledge temporary file hosting service.
+
+## Examples
+
+```bash
+# Uploading a file:
+$ omegaupload-cli upload https://paste.example.com path/to/file
+https://paste.example.com/PgRG8Hfrr9rR#I1FG2oejo2gSjB3Ym1mEmRfcN4X8GXc2pZtZeiSsWFo=
+
+# Uploading a file with a password:
+$ omegaupload-cli upload -p https://paste.example.com path/to/file
+Please set the password for this paste:
+https://paste.crabravers.club/862vhXVp3v9R#key:tbGxzHBNnXjS2eq89X9uvZKz_i8bvapLPEp8g0waQrc=!pw
+
+# Downloading a file:
+$ omegaupload-cli download https://paste.example.com/PgRG8Hfrr9rR#I1FG2oejo2gSjB3Ym1mEmRfcN4X8GXc2pZtZeiSsWFo=
+```
+
+## Features
+
+- Server has zero knowledge of uploaded data when uploading through a supported
+  frontend (Direct, plaintext upload is possible but unsupported).
+- Only metadata stored on server is expiration time. This is a strong guarantee.
+- All cryptographic functions are performed on the client side and are done via
+  a single common library, to minimize risk of programming error.
+- Modern crypto functions are used with recommended parameters:
+  XChaCha20Poly1305 for encryption and Argon2id for KDF.
+- Customizable expiration times, from burn-after-read to 1 day.
+
+## Getting Started
+
+Prerequisites:
+- `yarn` 1.22.17 or later (Earlier versions untested but likely to work)
+- [`trunk`](https://trunkrs.dev/)
+- Cargo, with support for the latest Rust version
+- _(Optional)_ zstd, for zipping up the file for distribution
+
+First, run `git submodule update --init --recursive`.
+
+Then, run `./bin/build.sh` for a `dist.tar.zst` to be generated, where you can
+simply extract that folder and run the binary provided. The server will listen
+on port `8080`.
+
+### Development
+
+For development, building is as simple as `cargo build`. Note that you may need
+to run `trunk build` first before building the server. To run the server (even
+for testing) requires uploading `dist.tar.zst` to a remote server.
+
+## Why OmegaUpload?
+
+OmegaUpload's primary benefit is that the frontends use a unified common library
+utilizing XChaCha20Poly1305 to encrypt and decrypt files.
+
+### Security
+
+The primary goal was to provide a unified library across both a CLI tool and
+through the web frontend to minimize risk of compromise. As a result, the CLI
+tool and the web frontend both utilize a Rust library whose crypto module
+exposes two functions to encrypt and decrypt that only accept a message and
+necessarily key material or return only necessary key material. This small API
+effectively makes it impossible to have differences between the frontend, and
+ensures that the attack surface is limited to these functions.
+
+#### Password KDF
+
+If a password is provided at encryption time, argon2 is used as a key derivation
+function. Specifically, the library meets or exceeds OWASP recommended
+parameters:
+ - Argon2id is used.
+ - Algorithm version is `0x13`.
+ - Parameters are `m = 15MiB`, `t = 2`, `p = 2`.
+
+ Additionally, a salt size of 16 bytes are used.
+
+#### Blob Encryption
+
+XChaCha20Poly1305 was used as the encryption method as it is becoming the
+mainstream recommended method for encrypting messages. This was chosen over AES
+primarily due to its strength in related-key attacks, as well as its widespread
+recognition and usage in WireGuard, Quic, and TLS.
+
+As this crate uses `XChaCha20`, a 24 byte nonce and a 32 bytes key are used.
+
+#### Secrecy
+
+Encryption and decryption functions offered by the common crate only accept or
+return key material that will be properly zeroed on destruction. This is
+enforced by the `secrecy` crate, which, on top of offering type wrappers that
+zero the memory on drop, provide an easy way to audit when secrets are exposed.
+
+This also means that to use these two functions necessarily requires the caller
+to enclose key material in the wrapped type first, reducing possibility for key
+material to remain in memory.
+
+#### Memory Safety
+
+Rust eliminates an entire class of memory-related bugs, and any `unsafe` block
+is documented with a safety comment. This allows for easy auditing of memory
+suspect code, and permits
+
+## Why not OmegaUpload?
+
+There are a few reasons to not use OmegaUpload:
+ - Limited to 3GB uploads—this is a soft limit of RocksDB.
+ - Cannot download files larger than 512 MiB through the web frontend—this
+   is a technical limitation of the current web frontend not using a web worker
+   in addition to the fact that browsers are not optimized for XChaCha20.
+ - Right now, you must upload via the CLI tool.
+ - The frontend uses WASM, which is a novel attack surface.