Hello,
ср, 18 сент. 2019 г. в 08:38, Niels Möller nisse@lysator.liu.se:
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
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.