[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] CK_ULONG considered harmful? -- current summary
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]