Mališa Vučinić writes:
> For pairwise (KeyIdeMode 0) things are bit different, for example
> sending beacons using pairwise keys is not really useful. So for
> pairwise keys key usages like 6TiSCH-K2-* are something that are
> usuful.
>
> I see what you mean. Essentially, key usage
Thanks for the clarification. I still have a couple of misunderstandings,
see inline.
Mališa
On Thu, Jul 19, 2018 at 12:47 AM Tero Kivinen wrote:
> Mališa Vučinić writes:
> > Thanks Tero for the proposal. Is the current "key_usage" registry enough
> to
> > fully configure the security tables fo
Mališa Vučinić writes:
> Thanks Tero for the proposal. Is the current "key_usage" registry enough to
> fully configure the security tables for the non-index modes?
I guess so. I mean in most cases the KeyIdModes 1-3 are similar, i.e.,
multicast/broadcast keys which are owned by somebody. In the Ke
Tero,
Thanks Tero for the proposal. Is the current "key_usage" registry enough to
fully configure the security tables for the non-index modes?
When a pledge/node receives a Link_Layer_Key corresponding to KeyIdMode 2,
how does it know which other node to use it for? i.e. I want to encrypt
data to
Malisa,
Can you please comment?
Thomas
On Wed, Jul 18, 2018 at 8:16 PM Tero Kivinen wrote:
> I think the Link_Layer_Key can very easily changed to send any kind of
> keys that are supported by 802.15.4.
>
> If it is updated as follows:
>
>Link_Layer_Key = (
>key_index : uint
I think the Link_Layer_Key can very easily changed to send any kind of
keys that are supported by 802.15.4.
If it is updated as follows:
Link_Layer_Key = (
key_index : uint,
? key_usage : uint / nint,
key_value : bstr,
? key_source : b