Review of AEAD Encryption API Project; concluding December 5, 2008
hartmans at MIT.EDU
Mon Dec 1 14:49:18 EST 2008
>>>>> "Love" == Love Hörnquist Åstrand <lha at kth.se> writes:
Love> Sam, Luke, all,
>> I believe it now includes enough of the GSS side API for
Love> Some more comments,
Love> iov_count should not be size_t, it should be unsigned
Love> int. size_t is to describe memory sizes, iov_count is not
I think this is a style question. On my C library at least, qsort and
calloc take size_t for their counts, while writev takes int. I don't
have a strong preference, but in the interest of making changes only
when there is a reason to do so, I'd say we should make this change
only if we get others calling for it.
Love> I think the iov should be before iov_count in the argument,
Love> just like in writev()/readv().
Luke? This makes sense to me.
Love> What do conf_state do to gss_wrap_iov_length() ?
Love> How does the consumer know the conf_req_flag/qop_req
Love> arguments when doing gss_unwrap_iov() ?
These are not arguments to the call to gss_unwrap_iov. I assume what
you're saying here is how does the unwrapper know what to pass in to
gss_wrap_length_iov? Luke, do you anticipate that the receiver of a
message would need to call wrap_length? I'd generally assume they
would either use a stream buffer or would already know the
Love> How does the consumer know the size of the header when in
Love> DCE mode, its always header + trailer ?
No, I'd expect that in DCE mode no trailer would be used.
It's my understanding that gss_wrap_iov_length will give you the header size.
More information about the krbdev