Open codahale opened 8 years ago
Not only that, it uses secret key as both key and IV (https://github.com/gophergala2016/meshbird/blob/aa0eb99d49f033b3280bf2cbe950c6316c88635a/common/net_table.go#L163) :-(
We working on strong encryption implementation with AES-256-GCM. 48h insufficiently for fully product implementation. We have decided to get working proof-of-concept before 48h will over.
You could follow us here: https://github.com/meshbird/meshbird https://twitter.com/meshbird
I understand. I still strongly recommend TLS, even instead of AES-256-GCM. It is very hard to design and implement a secure cryptosystem, and TLS already fits your use case.
We woud like to avoid using asymmetric keys in our case. And TLS is not good for UDP.
We have created related ticket 6 days ago https://github.com/meshbird/meshbird/issues/4
I noticed you're using AES-CBC for each packet, which I think is a mistake for a couple of reasons.
First, it's unauthenticated. If an attacker changes the encrypted packets, even if they don't know the key, they can propagate those changes into the plaintext without you knowing.
Second, it requires a padding scheme, which opens you up to chosen-ciphertext attacks via padding oracles. It depends on how the application is structured, but this can be catastrophic — an attacker can potentially decrypt data, even without the key.
Third, it doesn't protect against replay attacks. An attacker can re-send a particular packet, and you will have no way of knowing that happened.
I strongly recommend you use TLS. Go has wonderful support for it in the standard library with secure default configurations. If you want to avoid managing your own CA chain, you could use a whitelist of certificate fingerprints as a shared configuration to prevent unauthorized access.