I'm happy to look into doing a tutorial/app on this once I'm done with the ADC, I2C and SPI ones. I could then roll it all up into the iOS demo app as well if folks think that would be a useful addition.
Best regards, dg -- I'll take credit For the funny typos, the rest I blame on the iPhone spell wrecker. > On Dec 3, 2016, at 9:38 AM, Kevin Townsend <ke...@adafruit.com> wrote: > > > >> On 03/12/16 11:54, Tim Hutt wrote: >> Android and iOS don't allow you to specify the keys used by BLE's native >> encryption, but there is nothing stopping you using BLE as an insecure >> transport and implementing your own encryption on top of it (well apart >> from time, skill, and flash & RAM constraints). If you did that you would >> be able to use whatever keys you wanted because you implemented it. >> > This seems like something that would be nice to have as a proof of concept > demo in the core repo. I'm always interested in security, but it's far enough > outside my own core area of competence (HW design, RF and sensors) that I > know trying to roll my own code would do more harm than good and give a false > sense of security. If there are people on the dev list with up to date > experience in the field, I suspect a decent number of end users would benefit > from a basic starting point to encrypt BLE communication across a simple > service and characteristic set. The nRF52 isn't 'fast' in terms of clock > speed but it's still a reasonably capable chip with on board AES and single > precision HW floating point acceleration, and there is a decent amount of > flash and SRAM available.