Dmitry Eremin-Solenikov <dbarysh...@gmail.com> 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
