Once you've found a server administrator who provides the SafeWebdrop service all requests to the server rely on a https-based exchange of data to that server. Plain unencrypted (and unauthenticated) http cannot be used with SafeWebdrop.

Registration

The primary goal of registration is to have a user's RSA public key being accepted by the server administrator. The only reliable means to ensure that the user's public key is authentic is the first-hand contact to the server's administrator in which the registration code is presented. If the administrator checks this registration code before accepting a user's publick key, no-one else is able to smuggle a different key onto the server to overwrite the authentic one.

It should be said, that receiving the registration code first-hand is essential and must not be bypassed with any more convenient means of proof.

Because anything an attacker can do is to overwrite a user's registration with a different key in order to deny the user his registration for a time. The attacker will never succeed to register in a false ID unless the attacker is able to impersonate the user in a personal contact to the administrator using social engeneering tricks or worse. The legitimate user is asked to repeat his registration process until a valid request with the registration code conveyed first-hand is visible to the administrator.

From that point onwards, all requests to the server comprise of a unique challenge that is digitally signed with the legitimat user's RSA private key. The challenge (a 256 bit random number) must be provided in a signed message for every request that needs to be completed by the server. Replay attacks are prevented by generating a fresh challenge on the start of every new request.

As an additional means, no message or attachment file is stored on the server that is not AES encrypted.

So what can go wrong, once the user's public key is accepted?

If an atacker can utilize any other software on the server to execute code as the https process owner it is certainly possible to overwrite a user's legitimate public key, a file stored with access permissions of the https process owner. In this case, it is also possible for the attacker to copy messages and files that are encrypted and whose decryption key reside only on the sender's and the recipient's own devices in protected form. The legitimate user will notice this immediately as the server won't serve any of his messages any longer. A direct contact to the administrator is needed to resolve this problem caused by the unknown leaking code on the server.

Cross Server Contacts

The SafeWebdrop server allows two users that have been registered on different servers to exchange information (in fact a hash of both full SafeWebdrop addresses and their shared secret) to allow the use of a contact's public key on their own server. Note, that no contact between the two administrators nor the use of any PKI is involved. The conclusion of acceptance of a certain contact relies entirely on the secret, both users have agreed on.

An attacker can send a false request together with his illegitimate public key to be used as a contact, but the attacker will not be able to produce the neccessary hash value as he does not know the initial shared secret (ideally 20 random characters) between the two users. So the fake contact request will never conclude.

Both users have to make sure that the secret they agree on personally is not guessable or known to the attacker. The security of the CryptoBone's message exchange relies entirely on this intial secret agreement. It cannot be skipped or simplfied. Once both users have produced the same hash value (including their shared secret) and have provided it to the server, the contact's public key is stored and an attacker won't be able to overwrite it.

Client-side Attacks

If an attcker can run code on a user's device under the user's UID, the CryptoBone GUI can be used to initiate a new registration request (see above) so the attacker can destroy the user's ability to read his messages. The attacker's code will also be able to access currently stored messages and files on the device's RAM-disk through the GUI that have arrived recently and have been decrypted sucessfully. But this code cannot access the decryption keys that change with each message, because the key database is accessible by the cryptobone daemon only, so that forward secrecy is assured. The decryption keys that have already been used are discarded by the CryptoBone reliably. Details can be checked with the cryptobone daemon source code here.

Using the SafeWebdrop Exchange for your own Code

Of course, the SafeWebdrop exchange mechanism can also be used as a foundation for your own projects. The server-side scripts need not be changed at all. But you have to be extremely cautious when you are developing your own client-side code. If you don't avail of the cryptobone daemon to secure access to the message encryption keys, you have to think hard how to safeguard the encryption keys that are used in your own code. The secret, that protects the user's RSA private key must also be protected as much as possible, as every request is signed using this private key.

Given the vulnerabilities of certain popular Operating Systems this may not be an easy task.

To give you an idea of how the cryptobone daemon protects the database of secrets, I will briefly outline its functionality.

The cryptoboned process is started during the boot process by systemd (UID=0) and has access to the file system, in which the master key is stored. In a fraction of a second the cryptobone daemon has read the master key to decrypt the database of secrets and stores the clear text database in memory and discards the master key in memory. The process then mounts a different filesystem onto the directory in which the master key is stored making access to the master key impossible unless you can unmount this file system as root.

An attacker who has access to the client device during the boot process over a network connection has a very limited unpredictable time window in which the masterkey is visible at all. And even then root permissions protect the master key.

It is a very different story if an attacker can mount your primary OS partition because of physical access to your device. In this case you have to assume that your device is compromized entirely, so that access to the database of secrets will reveal current decryption keys only but not alredy used ones.

During normal operation the cryptobone daemon answers requests to secrets stored in the database in memory over a UNIX socket that can only be read by a process running under UID=0. So the GUI needs to selectively ask the daemon to perform actions in which encryption keys are needed.

As you can see, this mode of protection makes heavy use of UNIX capabilities and is not easily adaptable to other operating systems. That is the reason why I don't even think of trying to do that.