Hello, every: I have success to use sd_ecb_block function to encryption data. But I am not find how use this function to do decryption. Please teach me how to use this function, or give me a demo code. Thanks very much.
Hello, every: I have success to use sd_ecb_block function to encryption data. But I am not find how use this function to do decryption. Please teach me how to use this function, or give me a demo code. Thanks very much.
There is no hardware block to do ECB decryption in the nRF51822, and ECB encryption/decryption can be very insecure (see this Wikipedia page for an example).
I'd therefore strongly recommend you to instead use a AES mode which uses a hardware encryption block both for encryption and decryption, for example the counter mode. We don't currently have any example code for this, but it should be fairly easy to implement yourself.
yes, there simply isn't a decrypt block in the part since you actually don't want one Decrypt is only useful for ECB and CBC modes and there is a better one to use which is CTR. In CTR there is no decryption since you don't ever encrypt data, you use the encryption block to make a secure one time pad (OTP) both sides start from the same point (Nonce) and simply increment it and encrypt it to get the next 16 bytes of pad. This makes a stream cipher which means no more padding to get to 16 just shift off the number of pad bytes you need. Converting plain text to cipher text is just an xor and going back to plain is just xor again. This is more secure than CBC since the encryption step isn't dependent on previous data which also means that a bit flip doesn't propagate either and you can recover the stream minus the bit.
yes, there simply isn't a decrypt block in the part since you actually don't want one Decrypt is only useful for ECB and CBC modes and there is a better one to use which is CTR. In CTR there is no decryption since you don't ever encrypt data, you use the encryption block to make a secure one time pad (OTP) both sides start from the same point (Nonce) and simply increment it and encrypt it to get the next 16 bytes of pad. This makes a stream cipher which means no more padding to get to 16 just shift off the number of pad bytes you need. Converting plain text to cipher text is just an xor and going back to plain is just xor again. This is more secure than CBC since the encryption step isn't dependent on previous data which also means that a bit flip doesn't propagate either and you can recover the stream minus the bit.