Or some crap like that, I don’t know, never watched the show.
With technical requirements under our belts, we are moving on to design. This is going to encompass UI/UX design as well as technical design aspects such as database design, software architecture design, and overall system workflow.
There are a lot of things that we know, but still many questions left to answer. The thing that keeps sticking in my brain is the user experience that we want to facilitate. Our target audience is the general public, not just technically minded IT professionals. With this in mind, we want to make the service dead simple to use without making mistakes.
The current system that exists called Crypter works well enough, however it requires users to distribute not only a link to the encrypted file, but also a secret key to the right person. This presents a huge challenge to users. One thing to do is to deliver both in person, but if you are doing that, then there is no need to send an encrypted document digitally as it is, since you can more easily just give them a USB stick with the file. Other options that are commonly available to users is email, text messaging, or some other digital messaging service. In the case of the first two, they are not even kind of secure (unless you have encrypted email, but that is not something the general user is going to have set up, so it cannot be relied upon here). The last option, some other messaging service introduces another party into the mix that you have to trust. Many messaging services are not private and secure in the way that you would want them to be. Even services such as WhatsApp do use End-to-End encryption, which would make a compelling option, it is still owned and ran by Facebook (who have never spied on anyone’s data…..) and it requires both users to have an account set up with WhatsApp in addition to the file encryption service.
All in all, it seems counter to our mission to force users to select a sufficiently private means of communication (where statically most users will fail at this first crucial step), but a large part of our infrastructure is relying on this third party for communication. What I would like to do instead is to have some kind of unique key that is stored for every user that we can use to encrypt a unique encryption key for a file. This encrypted key would need to be able to decrypted by the targeted recipient and no one else, including our service, otherwise it defeats the purpose. This encrypted encryption key (lol) would then be packaged up with the encrypted file. The recipient would be able to unpack the key, decrypt it, then use the key to decrypt the file itself.
The beauty of this idea is that the sender or receiver does not have to know or do anything other than select the person they want to send the file to, and upload the file. Everything else can happen behind the scenes in the FTP service, making this a very user friendly, secure way to go. The biggest limitation that this imposes is that both the sender and receiver will have to have an account with the service already set up. We can mitigate this issue somewhat by allowing the sender to input an email address which we can send a signup invite to in order for that end user to sign up. There is a small issue here of if that user’s email is compromised, someone could sign up for them without them knowing, compromising the integrity of the service somewhat. This is not a very large concern, because the same thing could happen with the account on our service as it is.
Another issue that this idea creates is that the key we store would have to be unique to a specific device, meaning that a user could not just sign in with any device they have and get the file. We could allow users to registry multiple devices, each with their own public key, at that point we would just have to encrypt the file encryption key once per public key of the recipient user and send all of them along with a device ID of some kind. (For the device ID we would want it randomized and divorced from any actual data about the device so we don’t store that kind of personal information). Then when the user downloads the file, we decrypt the version of the key that corresponds to their device and then decrypt the file itself. This certainly adds some complexity and we have to send more information over the web, which is not ideal, however these encrypted keys should not be very large in size, so that part is not an overly large concern.
Looks like I need to do some digging and find out if this idea is even viable, as cool as it might be, we might need to come up with something more realistic if we find that this is just a pie in the sky idea.
Until next time, folks!