This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Function to encrypt all data to be sent

Hi,

Based on other discussions of encryption etc , I created a function to encrypt all the data, so that whenever I call the function It encrypts.

static   nrf_ecb_hal_data_t aes_struct;

static  uint8_t aes_data[16];

static   uint8_t aes_data_decrypted[16];

//Initializing arrays

memset (&aes_struct, 0, sizeof(aes_struct));

memset (aes_data, 0, sizeof(aes_data));

memset (aes_data_decrypted, 0, sizeof(aes_data_decrypted));

uint8_t* encrypt(uint8_t* p_data)
 {



        //Initializing key

        for (int i = 0; i < 16; i++)

        {
            aes_struct.key [i] = i;
        }

        //Initializing nouncence

        memset (aes_struct.cleartext, 0xaa, sizeof(aes_struct.cleartext)); //todo: use more random data and add counter

        //Creating chipertext

        sd_ecb_block_encrypt(&aes_struct); 

        //Encrypt -> XOR chipertext with p_data:



        for (int i = 0; i < length; i++)

        {  
            aes_data[i] = p_data [i] ^ aes_struct.ciphertext[i];
        }


        //decrypt -> XOR chipertext with Encrypted data:

        return (aes_data);

 }

 uint8_t* decrypt(uint8_t* p_data)
 {
    for (int i = 0; i < length; i++)

        {  
            aes_data[i] = p_data [i] ^ aes_struct.ciphertext[i];
        }


        //decrypt -> XOR chipertext with Encrypted data:

        return (aes_data);
 }

But I am not able to call the function, there's always an error

uint8_t vib_cnt_buf[5];
Convert_to_ascii(right,(&vib_cnt_buf[0]),8);
&vib_cnt_buf = encrypt(&vib_cnt_buf); //Encrypting this data

Can you please help

Parents Reply
  • Hi 

    I have to agree with Jörg here. If you are new to C development, then making your own encryption algorithm might not be the best place to start....

    The only advantage of cooking your own encryption is "security by obscurity", which isn't really security at all. 

    Have you investigated the security enhancements added to Bluetooth 4.2, namely the LE Secure Connections (LESC) pairing scheme?

    This was added as a response to the admittedly insecure pairing used in the original Bluetooth 4.0 implementation, and uses an industry standard Diffie Hellman key exchange algorithm to safely distribute encryption keys over a non secure channel. 

    The paper referred to in Daniel's blog is discussing the older pairing scheme in 4.0, and does not cover the enhancements in 4.2. 

    Unless you are able to implement a security scheme better than this then there really isn't any point adding another (less secure) layer on top. 

    Best regards
    Torbjørn

Children
Related