Playing with Encryption

The actual data to be transferred may not be strictly private, and one certainly had no issue letting others see it, but sometimes, one just want to had fun experimenting with something, useful or not. This time, we'll treat as if our data is so precious we can't afford leaking it. Let's see what can we do with it.

The first thing we need to ensure is the communication between the frontend and the backend. We already had an existing solution for that, using asymmetric public-private key (PGP). The server generates a pair and send the public key to the client, and vice versa in the other direction. Usually, using a persistent key is enough, but what if someone hacked into your computer, perhaps via remote desktop protocol (RDP), and steal the key? That won't be a problem if the key is single-use only, just like OTP. But of course, that means generating a new key for every transfer, which increase required computational power.

The extra problem comes when my backend is c# .net 9. The library they used, called BouncyCastle, still uses an old standard that's not acceptable by openpgp.js. The encryption key generated, if sent to frontend, requires setting a flag that allow such deprecated standard. Worse, anything encrypted with bouncy castle (whether the key pair is generated for the old or new standard) cannot be decrypted by openpgp.js. Therefore, we need some way to use the new standard. Unfortunately, one didn't understand the library deep enough to do they upgrade via monkey patching oneself. After trying to run JavaScript in my backend and failed, one finally resort to running gnupg, a command line callable process, via c# .net. If it didn't work out, one wouldn't be mentioning it. The drawback is calling a process makes things slow, but since one's using it for oneself, one don't really care. How slow? Literally about 5-7 seconds (including other processes) just to generate the data and encrypt it.

Now that we have a data transfer, but we need to verify that the frontend is from a legit source rather than a hacker's computer. The straightforward way is by using an OTP. And so that's what one had implemented. Though, the shared secret might be accessible by hackers if your computer get cracked, so again, it makes sense to generate an OTOTP (one-time OTP), where the shared secret is one use only and regenerates for each transaction. One can't really say it's safer that way or the other way, and common sense might we'll be common nonsense, but it certainly sounds cool, no?

If you want something cooler, you could use webauthn instead, but one didn't understand the logic behind it, so one had more difficulty implementing it and mixing it with other known strategies. Perhaps one can implement it per se, but in combination? Not really, not until one knows how it works.

With an otp, we can now verify we are legit after we communicate a shared secret for the first time. Before any communication is establish, we need to call a function to get the secret, but anyone can call that function. How can we be sure it is us that call it? One way to do that is fix an initial secret that we manually hardcode on both ends to set up the communication, but one had a better idea.

First, we generate 6 secret keys that will generate 6 OTP. Based on an algorithm, we decide which digit we'll take from each of the OTP to be recombined into a single OTP. Or perhaps you could choose another algorithm to decide which otp to use depending on what time it is, or a combination of 2 OTPs, or whatever. The backend should share the same algorithm, so we assume you had encrypted your code such that hackers can't easily see your compiled code and reverse engineer the algorithm. That means, even if the 6 shared secrets are stolen, without knowing how to combine them, it would be useless. Furthermore, we could, instead of comparing pure OTP, combine it with other strings and generate a hash. Yes, the md5 or Sha sum you find when downloading a file to verify it's integrity. For example, you could combine a string like "yourwebsite.com102345" or, by an algorithm, determine whether the website url would come first or the otp would come first, to further make it more difficult to guess. Then, you could also send only the first half or the last half of the algorithm, or ask for the nth digits which are determined by an algorithm, rather than sending the whole hash to the backend, further making it more difficult to guess and break through. Such are the fun of playing with encryption.

The storage of keys on the server, though, one had yet to think. Usually, if you restrict server access, it should be safe, but it cannot be confirmed.

On the other hand, mobile phones are more easily cracked into than a server, either by physical force (snatching it from the owner) or by other means, like accessing their phone via bluetooth. One also still cannot think much about how to secure it on phone except using Android keystore. (Sorry, never used iOS). But one doubt how safe it can be. Perhaps we could do another layer of encryption with xchacha20-poly1305 algorithm before storing it on Android preferences? But we still had to store the key and the nonce somewhere. Perhaps we could split the key into chunks and use a secret algorithm to rebuild it when we read? Same for the nonce? And use a different key and nonce every time we save? And perhaps we could add a requirement to use a passkey? One don't quite trust biometrics, because one can't be sure if anyone (especially since it's stored in, say, TPM, Trusted Platform Module, which is, as one read it somewhere, essentially a backdoor for the OEM to access your data) can steal the identity used for verification and verify in your stead. Not to say passkeys are any safer when they can also steal your digest... So one don't know.

Such are the fun of playing with encryption. Follow your curiosity, unrestricted to the strict rules of audit that had stripped all the fun from it, even if what comes out may not be safer and may have great flaws. But we make mistakes and we learn, right? So that's Ok.

What fun are you obsessed with? When did you follow your curiosity and forget about everything else and just follow it? Tell me by signing my guestbook!