I'm having a hard time figuring out how to do this and could use some advice.
Basically, I'm trying to create an encryption key from random numbers and a byte array that already exists. The byte array is a requirement and I want to add random numbers to make it more secure. Those random numbers will have to be shared with the decrypting side somehow, I know, but I have a plan for that.
Anyway, here's a little more info on the variables.
the random numbers are uint32_t because I am using the esp32's built in random number generator which is uint32_t.
So, basically, I want to be able to copy byte for byte (4 bytes for each uint32_t and 6 bytes for the other part) from the three variables into the key variable at specific locations.
I've tried some different things and can't seem to get it right. Any suggestions?
// Copy randomnumber1 into key starting from the first byte
memcpy(key, &randomnumber1, sizeof randomnumber1);
// Copy randomnumber2 into key starting from the fifth byte
memcpy(key + sizeof randomnumber1, &randomnumber2, sizeof randomnumber2);
// Concatenate otherpartofkey at the end of key
memcpy(key + sizeof randomnumber1 + sizeof randomnumber2, otherpartofkey, sizeof otherpartofkey);
First, let me say that i am fully aware that NOTHING is unhackable. That being said, I am NOT here for criticism or advice on the encryption methods, i did not ask for it and i am certainly not going to post publicly how i am planning to go about it. Whether it's something critically secret or just sometging to prevent interference, that's my business and not yours. Please do not ask again.
I tried memcpy and failed, could have typed something wrong being tired, but i see a difference in yours. Are parenthesis not required for sizeof in this case? I had sizeof(randomnumber1).
This looks very useful as well as it could let me split things if necessary.
I apologize if what o said sounded accusing, that was not my intention. I've just had a few posts that seem to go off topic because of someone asking things that have nothing to do with what i asked.
As far as how i think it would be more secure, random numbers added to anything makes it harder to break and/or repeat, so long as the receiving end has a way of knowing what they are besides the primary means of communications.
OMG, this made me laugh so hard! It can't be more accurate. The average person does not have the strength, will, or ability to not give in to drugs, booz or torture. Lol. Can't say that i would.
I will definitely try this when i get home tonight. I did not realize that.
That did the trick! I appreciate the help. This should get me started. Now I just need to figure out exactly what I'm going to make the key and how the other end is going to know. I have some ideas in mind, but this was the missing piece to put it all together.
The ESP32 has a unique ID you can get through espressif API. It has 6 or 8 bytes if I remember correctly
A bit outside topic as per your remark, but you need to look at your security stance. What are you protecting against and how you secure the keys at rest for example
Obviously YOU don't understand. Without "sharing" the encryption key with the other side, the other size won't know how to decrypt it without having to hack it. I specifically said, "besides the primary means of communications."
Just as an example to prove you wrong, one method of doing so would be to randomly generate these numbers (as suggested previously) and have them added to the key for a "paired" device, store this information (maybe even encrypted with an unshared key outside of the code) in the EEPROM or SPIFFS and either use a one-time pairing method to send that private key, or enter it into the other device manually (by hand, directly, through serial or web interface).
To start with, your flaw was assuming that I would do something however you see it in your mind, when there are probably thousands of ways I could do it. I never said that whatever I was doing was going to be random every single time, or just a random one-time thing each time the two ends/devices were paired together and could be re-paired any time to change it.
What I said is not wrong in the slightest bit. You just have no idea what I'm going to do, because I haven't given ANY details on it, and like to assume things.
So, please, move along and bother someone else with your all-knowing attitude. Because, I'm really tired of people saying stupid crap like this.
Yes, the uniqe ID is simply part of the MAC address. While it could be used, it may not be the most secure unless you come up with other methods to modify it in the encryption that it won't be obvious. The MAC address may be useful for the pairing itself though.
guys, I think you are not talking about the same thing.
@kb1sph1, you seem to have symmetric encryption in mind, which relies on a shared key between the sender and receiver for both encryption and decryption. Without sharing the key, symmetric encryption and decryption become challenging.
However, and I assume this is not what @Delta_G has in mind. There are methods that can achieve encryption and decryption without directly sharing the key such as the Diffie-Hellman key exchange which lets you establish a shared secret key over an insecure channel without explicitly sharing the key or you could use an Asymmetric Encryption (Public Key Cryptography) for key exchange. In this method, each party has a public-private key pair. The public keys can be freely shared, while the private keys are kept secret. One party can encrypt data with the recipient's public key, and the recipient can decrypt it with their private key and then you have all in between with Hybrid Encryption where you can combine symmetric and asymmetric encryption.
plenty of options to choose from and it's true that having to rely on side loading the keys is adding complexity and risks - as is of course storing the key in EEPROM or SPIFFS (unencrypted keys at rest are a low hanging target)
This was exactly my point. There are so many different options and all this post was really about was combining random 32bit integers into a byte array to help form a key. I mean, I could easily have a preset encryption key specific to my group of devices, then encrypt the individual keys with that to be sent to the device I'm pairing with. The key itself is not shared, but an encrypted version of it is. I could maybe even double encrypt the data with that and the key that was shared. While this won't be through a web interface, for simplicity, one could probably compare it to entering your password over an SSL connection. Even though it's secure, you're still using a separate key/password to authenticate. There are so many possibilities that one should not just assume any one of them.
Perhaps, but it's honestly not even the talk about encryption that bothers me so much as the people who just "assume" things without asking. And, when I've asked questions in the past, I seem to get responses like, "why do you even want to do that?" So, I figured at minimum I'd explain that it's for a key and that it has to be a byte array.
Completely untrue as my original post did not say anything about what methods i may or may not use.
Again, you are ASSUMING that I'm trying to emulate what a web page does exactly.
I full well know how SSH keys work. Again, you're ASSUMING i do not.
Things DO work exactly now i described them in some cases. You think you know it all, but you don't. There are different levels of encryption based on the needs of the user/developer and whether it's just a matter of preventing repeat (basically copy and paste) attacks, NSA level security or millions of possibilities in between.
I mean, technically Morse Code is a form of encryption, it's just widely known now and able to be decrypted by literally anybody.
You seem to have a single view of what encryption is, but you are wrong. Please see the following definition.
Over the years there have been numerous popular symmetric-key algorithms like Twofish, Rijndael (aka AES), Salsa20, ChaCha20, Blowfish, DES, 3DES and more I'm sure - some of which are now known to be insecure (like RC4) - but Symmetric key crypto does work OK for bulk encryption for example.
Yes, they come with the drawback of needing a shared secret between two or more parties and you have thus to find a way to share the secret "secretly", but @kb1sph1 was upfront on this and said
So I'm not too sure why there is this debate here...
From what I see @kb1sph1 is familiar with other types of encryption and has made a choice... that was not the purpose of his question...
