Review of AEAD Encryption API Project; concluding December 5, 2008

Sam Hartman hartmans at MIT.EDU
Mon Dec 1 14:57:26 EST 2008

>>>>> "Love" == Love Hörnquist Åstrand <lha at> writes:

    Love> Sam, Luke, thanks for waiting the whole long weekend for
    Love> comments.  I don't like making flags and type whole 32bit
    Love> fields but can live with it.

Is your concern that these are too big?

    Love> I don't like having a flag for sign only, even though that
    Love> more like how SSPI like does it, its a type and not a flag.

I agree.
Luke did this for compatibility with some work going on in the Samba community.
My preference would be to do it right and make this be a type.

    Love> I don't like that flags are not specified for what types
    Love> they are valid for.
That's a good point.
I've noted it as an issue to resolve before we go forward.
I think the answer is that sign_only only goes with data.
allocate and allocated go with all but data.

    Love> I don't like that there are no examples.
Want to write some?:-) Currently I think we only have resources
scheduled for the implementation and the necessary modifications to be
able to test this.  I don't think I have time in my schedule/budget
for examples, and I suspect that Luke will be fairly busy as well.  I
do completely agree that examples would be incredibly good here, and
if we could get some community member to work on them that would be

    Love> The second api, that I assume is called gss_*_aead, is not
    Love> at all specified. Even though its mentioned. Or is the
    Love> simpler interface STREAM ?

No, see gss_wrap_aead and gss_unwrap_aead.

    Love> gss_wrap_iov_length() is under specified.
In what way?

    Love> Re DCE, How does the caller now that know that the data is
    Love> correctly padded and how do they get the padding size of
    Love> before performing any operation given a gss_ctx_id_t ?

    Love> I'll sure there should be more questions showing up when
    Love> this is tried out more. But lets start with these.

O, yes, I'm sure we'll get questions when we implement using code:-)

More information about the krbdev mailing list