Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Development
  3. software AES encryption for NRF24

software AES encryption for NRF24

Scheduled Pinned Locked Moved Development
43 Posts 9 Posters 21.3k Views 12 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • FotoFieberF FotoFieber

    @Anticimex
    No IV? Then the AES Transport implementation is not secure, more ore less an obfuscation...

    Is this a known bug, that will be fixed?

    AnticimexA Offline
    AnticimexA Offline
    Anticimex
    Contest Winner
    wrote on last edited by
    #41

    @FotoFieber it is a known limitation and is currently not in scope for improvement for nrf24 because it require reliable sync which nrf radios are notoriously bad at providing. If you have an idea on how to fix it, a pr is always welcome :)

    Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)

    1 Reply Last reply
    0
    • FotoFieberF Offline
      FotoFieberF Offline
      FotoFieber
      Hardware Contributor
      wrote on last edited by
      #42

      Hm, I am not an encryption expert. What about a Diffie-Hellmann key exchange and then use the key as IV?

      1 Reply Last reply
      0
      • AnticimexA Offline
        AnticimexA Offline
        Anticimex
        Contest Winner
        wrote on last edited by
        #43

        Me neither. I care about security, not obscurity. I see no reason to encrypt a '1' or a '0' and digital streams like audio and video is not supported anyway. But exchange of constant (but random) data is already used and supported since signing is based on nonce exchange. But I believe IV:s "evolve" with the messages encrypted which implies the messages need to be exchanged trustworthy and sender and receiver need to be om sync. But I know to little about that to be sure.
        In any case, I welcome any development that adds to security, and will happily review such code, but I don't have the bandwidth nor motivation to "drive" the development of encryption in the core library as I don't feel it adds enough value to be worth the effort.

        Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        11

        Online

        11.7k

        Users

        11.2k

        Topics

        113.1k

        Posts


        Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • MySensors
        • OpenHardware.io
        • Categories
        • Recent
        • Tags
        • Popular