Hello,
ср, 18 сент. 2019 г. в 08:38, Niels Möller <ni...@lysator.liu.se>:
>
> 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 }.
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
