Lots and Lots of Info!

How to Use In a nutshell.

Create a group, invite others by email address, accept or decline the invite, publish to a group, download from a group.

Publishers and Subscribers Group Sharing.

Blindrelay uses a simple group publish and subscribe model. The group 'organizer' creates and manages a group. Members of a group, designated by the organizer as publishers, first encrypt files locally using a shared 256bit AES group key and then upload the encrypted files to blindrelay. Keys are themselves encrypted and decrypted on group member devices so blindrelay servers have no way of decrypting files published to blindrelay servers. Blindrelay servers are virtually blind.

Multiple sharing scenarios are supported: single publisher multiple subscribers, multiple publishers multiple subscribers, single subscriber multiple publishers, single subscriber single publisher, etc. You can even create groups where you are the only member.

Group member invitees may accept or decline group invites and can deactivate themselves at any time. Files are only published to active group subscribers. Group organizers may deactive or delete a user from a group at any time. Deactivated users may be activated again, but deleted users can never rejoin the group.

Group organizers may delete a group at anytime. However, group publish and download statistics will remain on the server after deleting the group.

Single Publisher Multiple Subscribers Generic placeholder image

Email Addresses Simple identification.

Only an email address is used to identify users. No personal information, such as a person's name is required (or even asked for) by blindrelay. When registering a new account in the blindrelay app, the user provides an email address and desired password. Neither the email address nor the password are sent to blindrelay in reversible or readable forms. With one exception: email addresses are needed during the registration process by blindrelay to send email address confirmation emails. (For this reason the blindrelay app has a built in support ticket system since blindrelay does not store email addresses. See below.)

After registering, a confirmation email with a link is sent to the user to confirm email account access.

The user cannot sign into the blindrelay app until the email address has been confirmed. After email confirmation, the user signs into the blindrelay app using the password used during registration. Standard stuff.

Why no two-factor authentication (2FA)? Traditional 2FA is a hassle and annoying. Blindrelay uses a random one-time registration code during the email confirmation process. In addition, when creating a group, the group organizer can require that invitees enter a prearranged password before joining the group. What password the organizer sets (optional) and how that password is communicated to invitees is up to the organizer (use a meeting room or maybe a messenger pigeon!) The group join password is PBKDF2SHA256 hashed on the group organizer's device before storing on the server and can be used as another authentication factor.

But wait. How about nFA? Using File Protector, encrypt files (n times using n pre-shared passwords) before uploading to the group. Probably overkill...

If you're worried about someone else using your blindrelay account, do not use the same password for the blindrelay app that you use on your devices, bank accounts, email accounts, social media accounts, work accounts, etc.!

Group Create in blindrelay App

Encryption All the way!

All file encryption and decryption happen on user devices, not blindrelay servers. Blindrelay servers cannot decrypt files because blindrelay servers cannot access encrypted (wrapped) 256bit AES encryption keys.

After files are published, users designated by the organizer as group subscribers may download encrypted files to their devices, where the files remain encrypted until the user decides to decrypt them. The integrated Encrypted Download Manager is used to decrypt files locally and users do not need to be concerned with key management.

The Encrypted Download Manager also includes a preview options where the user can click on an encrypted PDF, media, or text file to preview.

You do not need to concern yourself with encryption keys or the actual encryption/decryption process; blindrelay manages this for you.

Group Create in blindrelay App

Group Create in blindrelay App

Support Built in.

Because blindrelay servers do not store emails, phone numbers, or other personally identifiable information (PII), communication with the user is a bit more challenging. For instance you may want a new feature added to the app or want to report an issue, and blindrelay may need to respond.

To handle these situations and to broadcast system notifications to the user from time to time, the blindrelay app has a support ticket and notification system built in. One thing to note: support ticket information is not encrypted at rest (blindrelay servers cannot decrypt and support staff may need to read the tickets!), but is transmitted back and forth between the blind relay app and servers over secure HTTPS.

However, all notifications are encrypted at rest and transmitted, encrypted, over HTTPS. Although blindrelay servers can encrypt notifications using a users 4096bit public RSA key, blindrelay servers cannot decrypt notifications! All notification decryption happens on user devices.

Technical Details TL;DR.

All communications between the blindrelay app and servers are over secure HTTPS.

In the app, user passwords are PBKDF2SHA256 stretched and hashed with the email as salt over 10,000 iterations on the user's device before being sent to blindrelay servers. This scheme is used only to ensure that plain text passwords do not get sent to the server and do not end up in log files or the eyes of developers.

At the server, hashed passwords from the client are then peppered and PBKDF2SHA512 stretched and hashed with the user's 512bit password salt over 10,000 iterations. The 512bit password salt is randomly generated (using CSRNG) during user registration and stored on the server and used to generate the 512bit stretched and hashed final password representation stored on the server for authentication.

256bit AES encryption keys are protected by the user's password PBKDF2SHA256 stretched and hashed with the user's 256bit encryption salt over 10,000 iterations on the user's device. The 256bit encryption salt is randomly generated (using CSRNG) during user registration and stored on the server.

The first time a user signs into the blindrelay app, a 4096bit RSA public/private key pair is generated by the user's device. (This is why first sign in takes longer than usual. RSA key pair generation time is dependant on device performance.). The private key is encrypted on the users device with an encrypted 256bit AES encryption key (wrapped) and both the public (x509 Certificate) and encrypted private keys are stored on blindrelay servers.

The 4096bit RSA public key is used by blindrelay servers to encrypt some notifications that the user can then decrypt on their device. It is also used by group organizers to locally encrypt the 256bit AES group key before sending over the wire.

The user's email is PBKDF2SHA256 stretched and hashed with an internal salt over 10,000 iterations on their device to create a non-reversible, yet deterministic identifier for the user to ensure that email addresses do not end up in log files. Blindrelay servers do not store email addresses, IP addresses, or other PII. The only time email addresses are used by blindrelay is for sending email address confirmation emails. If blindrelay needs to contact users, it will be done with encrypted anonymous notifications within the blindrelay app or normal support ticket system workflow.

Encrypted information (files and server stored information) is stored using blindrelay's 'CryptoBuffer' format. Wrapped encryption keys are not embedded in CryptoBuffer packages.

Files published to a group are first GZip compressed, encrypted, HMACSHA256 signed, and then streamed over HTTPS and stored in Microsoft's Azure BLOB storage for download by group subscribers.

Group organizers may set a Time to Download, which can range from 1 minute to 6 days. Uploaded files expire after the Time to Download passes since the files were published. Expired files get deleted on the server and cannot be downloaded by subscribers. Larger files will require a longer Time to Download.

Blindrelay's server data structures are stored in Microsoft's Azure Cosmos DB, enabling global distribution.

Generic placeholder image