NRF51 Port #92
Draft
NRF51 Port #92
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…u4 talking to nrf51 via uart) and the nrf51 in general (for keyboard transmitters)
bezmi
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Putting this here as I work on integrating the nrf51 chips via the ESB protocol for the following use cases.
Mitosis receiver with atmega32u4 and nrf51 communicating via uart. Encryption to be done by the nrf51 built in hardware (see discussion below)
Mitosis/chimera/orthrus wireless split keyboards, where each half contains an nrf51 board that transmits to the receiver above.
The only challenge I foresee is the crypto hardware of the nrf51/nrf52 series. These chips can only do encryption via AES and are designed to be used with CTR based modes of operation which only rely on encryption operations. They all have BLE compliant AES-CCM hardware that can perform authenticated encryption/decryption, where each packet is a 27 byte payload + 1 byte length field + 4 byte message integrity check. The nrf52840 is an exception here, as it has ARM CryptoCell which should be able to do decryption of AES ciphertext.
I will just implement software based decryption using cifra, the nrf51 chips should be able to do this fast enough for a keyboard.
Using the built in AES-CCM hardware has the benefit of being able to encrypt/decrypt packets on the fly as they are being transmitted/received and is also the most straightforward implementation in the nrf5 series. However, it also means either a rewrite of the existing security code for the AVR, or having two different security protocols coexist. Not sure how to proceed here. I don't believe CCM is optimal for the small (1 block) stream that keyplus.