Re: [pkcs11] CK_ULONG considered harmful? -- current summary

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

On 05/28/2013 10:34 AM, Chris Zimman wrote:
> > There are two distinct items here:
> >
> > 1) Clarifying CK_ULONG (if necessary) for the general case.
> >
> > -- There appears to be no current issue for the use of the variable length type within the same process space.
> > -- There may be some issues for supporting values of this type where there is an intermediate (e.g. network connected) form/protocol. That may suggest locking the type to a > fixed length, or at least constraining the values so that there can always be a loss-less conversion to/from
> > the intermediate form.   That's (special processing) already required
> > for handle-like objects.
> >
> > 2) Providing support for 64 bit lengths for C_Encrypt, C_Decrypt etc.
> >
> > -- This is actually a second, and more interesting issue.  CK_ULONG is used as a length type for the various data processing commands (e.g.
> > C_Encrypt, C_Decrypt, C_Digest etc).    If the local typing has this as
> > a 32 bit value, a single call is limited to 4 gig of data.  The work around - as usual, is to break up the chunks into less than 4 gig and call the C_*Update routine.
> >
> > -- Should the maximum values for CK_ULONG be clarified for the existing routines to be uint32_t.MAX-1?
> > -- and/or Should there be additional routines that support a uint64_t type for length?
> > -- Or is this a don't care?  (e.g. it's up to the caller to determine whether the HSM supports uint64_t lengths and to use > 4G buffers).
> My current understanding is that this is going to be deferred to >= 3.0

Agreed.

Good write-up, Michael.