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

[Michael StJohns <msj@nthpermutation.com>]

On 5/21/2013 5:03 PM, Andrey Jivsov wrote:
> IMO the bigger problem is with lengths. There are a lot of them in 
> these headers that use CK_ULONG. 

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).