Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Hello,
ср, 18 сент. 2019 г. в 08:38, Niels Möller :
>
> Dmitry Eremin-Solenikov writes:
>
> >> 2. What should be the behavior for usage like
> >>
> >>->set_key
> >>->set_nonce
> >>->update
> >>->digest
> >>->update
> >>->digest
> >>
> >>with second set_nonce missing?
> >>
> >>Should it just keep the nonce from the first digest? (Sounds a bit
> >>dangerous). Or autoincrement? (That's what umac does, because it's
> >>defined in a way to make that more efficient). Or be specified as
> >>invalid, triggering asserts whenever it is easy to detect?
> >>
> >>I think it has to be specified; it will be too confusing if UMAC
> >>behaves in one way and GMAC behaves differently.
> >
> > I'd say that this is an undefined behaviour. So, if one needs fully
> > predictable result, he should set nonce each time. For GMAC nonce MUST
> > be set each time to a new value. For UMAC one can skip this call. We
> > might want to refine this UB later.
>
> I would prefer to have it nailed down. It kind-of defeats the purpose of
> a nettle_mac abstraction if code using it is expected to have if (umac)
> { do this } else { do that }.
I'd propose then that if one uses generic interface, he MUST set nonce
each time. If one wishes to use auto-increment option of UMAC, he is
already tied to UMAC and thus doesn't have to use generic interface at
all.
> > Consider other MACs (like Kasumi F8/Snow3G UIA2/ZUC EIA3) which
> > require nonce, can have nonce autoincrement, but with complex rules.
>
> Complex how? If it is a common usecase, one could consider to either do
> auto-increment always (part of ->digest, like currently done for umac),
> or have a separate method increment_nonce or so.
Complex as incrementing a value in the middle of nonce by the amount
of bytes processed in the call. Again I think now, that it might be
easier to demand calling set_nonce when using generic interface.
> > BTW: I have written a library with 3GPP encryption/integrity
> > alogorithms. The library follow closely Nettle interface. I can
> > publish it and/or submit into nettle for inclusion. However I am
> > completely unsure about patent status and enforcement for those
> > algorithms. Do you know if somebody can advice me on this topic?
>
> It's time consuming to research patent status (and usually impossibly to
> reach certainty). Maybe you could ask FSF or sfconservancy lawyers, and
> say you consider contributing an implementation to GNU Nettle, but I
> doubt they have the resources to do a thorough investigation. If you
> know the patent holders, you could mail and ask them, or check if
> there's any general patent policy for 3GPP members. Reviewing any
> licensing terms they offer should be an easier task for FSF lawyers than
> a more open-ended patent investigation.
I have received no significant response from FSF, FSFE and
sconservancy (maybe I was asking a wrong question though). Just
typical "patent research is costly and we do not do consulting".
Anyway, patent licenses are explicit about using these algorithms to
only implement actual 3GPP/LTE support. So they should not target
generic library.
--
With best wishes
Dmitry
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Dmitry Eremin-Solenikov writes:
>> 2. What should be the behavior for usage like
>>
>>->set_key
>>->set_nonce
>>->update
>>->digest
>>->update
>>->digest
>>
>>with second set_nonce missing?
>>
>>Should it just keep the nonce from the first digest? (Sounds a bit
>>dangerous). Or autoincrement? (That's what umac does, because it's
>>defined in a way to make that more efficient). Or be specified as
>>invalid, triggering asserts whenever it is easy to detect?
>>
>>I think it has to be specified; it will be too confusing if UMAC
>>behaves in one way and GMAC behaves differently.
>
> I'd say that this is an undefined behaviour. So, if one needs fully
> predictable result, he should set nonce each time. For GMAC nonce MUST
> be set each time to a new value. For UMAC one can skip this call. We
> might want to refine this UB later.
I would prefer to have it nailed down. It kind-of defeats the purpose of
a nettle_mac abstraction if code using it is expected to have if (umac)
{ do this } else { do that }.
> Consider other MACs (like Kasumi F8/Snow3G UIA2/ZUC EIA3) which
> require nonce, can have nonce autoincrement, but with complex rules.
Complex how? If it is a common usecase, one could consider to either do
auto-increment always (part of ->digest, like currently done for umac),
or have a separate method increment_nonce or so.
> BTW: I have written a library with 3GPP encryption/integrity
> alogorithms. The library follow closely Nettle interface. I can
> publish it and/or submit into nettle for inclusion. However I am
> completely unsure about patent status and enforcement for those
> algorithms. Do you know if somebody can advice me on this topic?
It's time consuming to research patent status (and usually impossibly to
reach certainty). Maybe you could ask FSF or sfconservancy lawyers, and
say you consider contributing an implementation to GNU Nettle, but I
doubt they have the resources to do a thorough investigation. If you
know the patent holders, you could mail and ask them, or check if
there's any general patent policy for 3GPP members. Reviewing any
licensing terms they offer should be an easier task for FSF lawyers than
a more open-ended patent investigation.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Daiki Ueno writes: >> 1. Comment says "suggested nonce_size", but I take it only that one size >>is possible, since set_nonce is nettle_set_key_func, with no length >>argument. Or do you intend to allow other sizes? >> >>I think I'd prefer fix size, to keep things simple. And treat >>variants with different nonce size as separate mac algorithms, for >>this abstraction. Just like with the key size. > > I think fixed size would be sufficient (the code was merely copied from > the nettle_aead definition). Good. > Provided that the two types of MACs (nonces are required or not) are > supposedly not intermixed, another option might be to provide a separate > struct (say, nettle_nmac) for MACs that require nonces (UMAC and GMAC, > not sure if there will be more to come), and mandate set_nonce != NULL: > > - nettle_mac (from the testutils.h definition) for HMAC, CMAC > - nettle_nmac (nettle_nmac + set_nonce) for UMAC, GMAC Makes sense. One would then only need a good name. Is there any standard terminology distinguishing between these two variants? But I'm fine with a single struct, provided that it's clearly specified how the set_nonce call is expected to be used. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
вс, 15 сент. 2019 г. в 10:28, Niels Möller : > > Dmitry Eremin-Solenikov writes: > > > There will be a nonce for GMAC. > > Ok. If we keep set_nonce, we have to clarify what it means. There are a > couple of cases, where the first two are relatively easy. > > nonce_size == 0, set_nonce == NULL: > Never call set_nonce. This is the HMAC case. Fine with me > > nonce_size == 0, set_nonce != NULL: > This could mean that nonce is optional. Does that make any sense? I don't think we should allow such constructions. Neither UMAC nor GMAC make optional use of nonce. And if we think further, 3GPP MAC algorithms, which make use of nonce, also have non-optional fixed size nonce. > > nonce_size > 0, set_nonce != NULL: > Would then be used for UMAC and GMAC. Fine with me > > For the last case, I have a couple of questions. > > 1. Comment says "suggested nonce_size", but I take it only that one size >is possible, since set_nonce is nettle_set_key_func, with no length >argument. Or do you intend to allow other sizes? > >I think I'd prefer fix size, to keep things simple. And treat >variants with different nonce size as separate mac algorithms, for >this abstraction. Just like with the key size. Fix size. If one needs variable nonce size, he can use full interface. > 2. What should be the behavior for usage like > >->set_key >->set_nonce >->update >->digest >->update >->digest > >with second set_nonce missing? > >Should it just keep the nonce from the first digest? (Sounds a bit >dangerous). Or autoincrement? (That's what umac does, because it's >defined in a way to make that more efficient). Or be specified as >invalid, triggering asserts whenever it is easy to detect? > >I think it has to be specified; it will be too confusing if UMAC >behaves in one way and GMAC behaves differently. I'd say that this is an undefined behaviour. So, if one needs fully predictable result, he should set nonce each time. For GMAC nonce MUST be set each time to a new value. For UMAC one can skip this call. We might want to refine this UB later. Consider other MACs (like Kasumi F8/Snow3G UIA2/ZUC EIA3) which require nonce, can have nonce autoincrement, but with complex rules. BTW: I have written a library with 3GPP encryption/integrity alogorithms. The library follow closely Nettle interface. I can publish it and/or submit into nettle for inclusion. However I am completely unsure about patent status and enforcement for those algorithms. Do you know if somebody can advice me on this topic? -- With best wishes Dmitry ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Hello, ni...@lysator.liu.se (Niels Möller) writes: > Dmitry Eremin-Solenikov writes: > >> There will be a nonce for GMAC. > > Ok. If we keep set_nonce, we have to clarify what it means. There are a > couple of cases, where the first two are relatively easy. > > nonce_size == 0, set_nonce == NULL: > Never call set_nonce. This is the HMAC case. > > nonce_size == 0, set_nonce != NULL: > This could mean that nonce is optional. Does that make any sense? > > nonce_size > 0, set_nonce != NULL: > Would then be used for UMAC and GMAC. > > For the last case, I have a couple of questions. > > 1. Comment says "suggested nonce_size", but I take it only that one size >is possible, since set_nonce is nettle_set_key_func, with no length >argument. Or do you intend to allow other sizes? > >I think I'd prefer fix size, to keep things simple. And treat >variants with different nonce size as separate mac algorithms, for >this abstraction. Just like with the key size. I think fixed size would be sufficient (the code was merely copied from the nettle_aead definition). > 2. What should be the behavior for usage like > >->set_key >->set_nonce >->update >->digest >->update >->digest > >with second set_nonce missing? > >Should it just keep the nonce from the first digest? (Sounds a bit >dangerous). Or autoincrement? (That's what umac does, because it's >defined in a way to make that more efficient). Or be specified as >invalid, triggering asserts whenever it is easy to detect? > >I think it has to be specified; it will be too confusing if UMAC >behaves in one way and GMAC behaves differently. Provided that the two types of MACs (nonces are required or not) are supposedly not intermixed, another option might be to provide a separate struct (say, nettle_nmac) for MACs that require nonces (UMAC and GMAC, not sure if there will be more to come), and mandate set_nonce != NULL: - nettle_mac (from the testutils.h definition) for HMAC, CMAC - nettle_nmac (nettle_nmac + set_nonce) for UMAC, GMAC That would be analogous to the distinction between nettle_cipher and nettle_aead and serve the documentation. Regards, -- Daiki Ueno ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Dmitry Eremin-Solenikov writes: > There will be a nonce for GMAC. Ok. If we keep set_nonce, we have to clarify what it means. There are a couple of cases, where the first two are relatively easy. nonce_size == 0, set_nonce == NULL: Never call set_nonce. This is the HMAC case. nonce_size == 0, set_nonce != NULL: This could mean that nonce is optional. Does that make any sense? nonce_size > 0, set_nonce != NULL: Would then be used for UMAC and GMAC. For the last case, I have a couple of questions. 1. Comment says "suggested nonce_size", but I take it only that one size is possible, since set_nonce is nettle_set_key_func, with no length argument. Or do you intend to allow other sizes? I think I'd prefer fix size, to keep things simple. And treat variants with different nonce size as separate mac algorithms, for this abstraction. Just like with the key size. 2. What should be the behavior for usage like ->set_key ->set_nonce ->update ->digest ->update ->digest with second set_nonce missing? Should it just keep the nonce from the first digest? (Sounds a bit dangerous). Or autoincrement? (That's what umac does, because it's defined in a way to make that more efficient). Or be specified as invalid, triggering asserts whenever it is easy to detect? I think it has to be specified; it will be too confusing if UMAC behaves in one way and GMAC behaves differently. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
сб, 14 сент. 2019 г. в 13:47, Niels Möller : > > Daiki Ueno writes: > > > From: Daiki Ueno > > > > The changes from the previous series are: > > - remove the global hmac_*_set_key_expanded functions > > - leave out set_nonce member if the operation is not supported > > > > For the latter, I was wondering whether it is better to define a no-op > > set_nonce, but given the fact that that the caller nevertheless checks > > nonce_size, I chose to make the field blank. > > I'm a bit uneasy about the set_nonce pointer. It's used only for umac, > where nonce use is a bit peculiar with the auto-increment optimization. > > Would it be ok to leave umac out, and move the definition of nettle_mac > from testutils.h as is (except that the comment "other sizes are > sometimes possible" on the key_size field seems wrong)? There will be a nonce for GMAC. > Then nettle_mac is very similar to nettle_hash, one just calls ->set_key > instead of ->init, and one can then hash several messages with the same > key using a sequence of ->update and ->digest calls. > > Regards, > /Niels > > -- > Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. > Internet email is subject to wholesale government surveillance. > ___ > nettle-bugs mailing list > nettle-bugs@lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs -- With best wishes Dmitry ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
Daiki Ueno writes: > From: Daiki Ueno > > The changes from the previous series are: > - remove the global hmac_*_set_key_expanded functions > - leave out set_nonce member if the operation is not supported > > For the latter, I was wondering whether it is better to define a no-op > set_nonce, but given the fact that that the caller nevertheless checks > nonce_size, I chose to make the field blank. I'm a bit uneasy about the set_nonce pointer. It's used only for umac, where nonce use is a bit peculiar with the auto-increment optimization. Would it be ok to leave umac out, and move the definition of nettle_mac from testutils.h as is (except that the comment "other sizes are sometimes possible" on the key_size field seems wrong)? Then nettle_mac is very similar to nettle_hash, one just calls ->set_key instead of ->init, and one can then hash several messages with the same key using a sequence of ->update and ->digest calls. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH v2 0/6] Add meta interface for MAC algorithms
пн, 22 июл. 2019 г. в 11:54, Daiki Ueno : > > From: Daiki Ueno > > The changes from the previous series are: > - remove the global hmac_*_set_key_expanded functions > - leave out set_nonce member if the operation is not supported > > For the latter, I was wondering whether it is better to define a no-op > set_nonce, but given the fact that that the caller nevertheless checks > nonce_size, I chose to make the field blank. Looks good to me now, thank you. -- With best wishes Dmitry ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
