Gazell pairing library only support one encrypted pipe?

[Constantin]

I've just read it and I am a bit puzzled? Could you explain why? I was planning to use gzll with one master and two clients where I would need to have at least two encrypted pipes.

Thanks, Constantin

[ovrebekk]

Hi Constantin

When Gazell (and GZP in particular) was designed the primary use case was wireless desktop solutions, where you would typically have one keyboard, one mouse, and perhaps some remote controls or game controllers connected to the same USB receiver.

The encrypted pipe was dedicated to the keyboard, which would obviously require encryption to avoid people picking up passwords and similar. For mice, game pads and remotes encryption is less important, because the information doesn't provide any value unless you know the exact state of the computer, the position of the mouse at all times, what it is pointing at and so forth. These would use the un-encrypted pipes.

So that was the motivation behind it :)

Best regards
Torbjørn

[Constantin]

Ok. So then it does not make sense to use gzll instead if esb if I have to build encryption on my own. Is the AES HW function available if I am trying to use BLE and ESB in a concurrent timeslot setting?

[ovrebekk]

Gazell still provides frequency jumping, which ESB does not, so if you need that I would stick to Gazell. You might have to implement your own encryption and pairing library on top though (you would also have to do that for ESB).
In a timeslot you can access the AES module freely, and outside the timeslot there is an API in the SoftDevice allowing you to access it indirectly (it will be scheduled by the SD to avoid affecting the BLE link).

[Constantin]

Okay, thanks I will ESB give a try.