@NicHartley Depends on the question, really. We don't do homework, but we can certainly point out potential flaws in a proposed scheme, if the question is well-written and specific.
There are a lot of well-received questions that amount to "is there anything wrong with this idea?"
Well if it's specific to cryptography, then Cryptography would be better, but they don't accept "analyze this scheme" questions.
@NicHartley Well I see a [code-review] tag.
There are also tags for threat modeling.
So an encryption protocol?
Such a question might be too broad if you aren't asking about specific attacks.
Or if you don't have a very specific threat model.
Read the TLS1.3 RFC, specifically the section on design decisions. It is quite helpful if you're designing your own protocol. You'll learn why it's so important to use a different key for traffic in each direction, for example, as well as how to handle nonces and authentication and all that.
The SSH encryption protocol is also useful to read up on, but it's not as well documented.
Encrypting data in-transit is far harder than encrypting data at-rest, because you have to deal with an active attacker, so all sorts of new threats become relevant (replay, reflection, etc.).
I could write secure file encryption software in my sleep, but it'd take some serious effort and a lot of thought to design a new encryption protocol against more than the most trivial threats.
@NicHartley Yeah, SSH is a pretty crazy protocol.
Well TLS is in a layer that's agnostic to the underlying protocol.
It can be used over pipes, packets, messenger pigeons...
Although it does have some basic assumptions that the underlying protocol is packeted, as evidenced by its support of TLS record fragmentation.
And here, my toy project is end-to-end encrypted file backups to cloud servers, to mitigate ransomware attacks... Obviously I'm not thinking nearly grand enough.
The limits of my knowledge in that area are: arduinos make it easy to control a couple servos and flash a couple LEDs... and getting anything meaningful to show on a screen is hard.
The kind of hardware I'm interested in is consumer stuff like hard drives.
I've been planning on REing some hardware firmware and modifying it to add anti-forensics.
Something akin to port knocking, but in an HDD. Sector knocking?
Read a few specific sectors in the right order using the ATA read command directly before reading anything past the MBR. Any reads past the MBR without knocking would trigger ATA Security Erase.
Interesting. First use case I could see for it would be portable hard drives. Don't plug it into a computer that you don't have customized drivers for it.
My project's big question is, how do I keep a list of files (including versions of files), and serve it to the end user in an efficient way, without me being able to infer anything about the data, including metadata about metadata... And without them needing to supply their private key to the client-side program on bootup/file change -- only need it when restoring from backup?
I've got a nice long weekend ahead to puzzle that out, though... :D
Client side would create a large symmetric key, encrypt that key with their public key... Use the symmetric key to encrypt files directly (and provide the encrypted version to the server for backup purposes). In order to decrypt the files, you'd need to decrypt the symmetric key's backup. That's the only time you'd need the private key.
As I said, there's a long weekend for me to think it through. The one thing I don't ever want is responsibility (culpability) for someone else's data.
