OASIS Open Mailing List Archives  ·  All Lists  ·  pkcs11  ·  2013-04

pkcs11 — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length


I describe a solution that I think Valerie alluded to that would work for all platforms as far as covering the difference between Well ... which is it? It should be either: (1) CK_ULONG ulPasswordLen; or (2) CK_ULONG_PTR pulPasswordLen; On all operating systems the first page of the process's address space is protected, so that the addresses in the range of 0 - 512 are always illegal and cannot be valid pointers. Notice that a password length fits into this range. This can be used to distinguish between these cases. Let's say we are, the library, are trying to identify which interpretation for the value P the caller is using: the (1) or (2). In terms of C language, when the P is cast to the numeric value of type size_t (that is guaranteed to accommodate a pointer void *) whether P is a ULONG or ULONG_PTR, denoted here as (size_t)P, it follows that    if (size_t)P < 512  => client uses case (1)    else => client uses case (2). Most compilers contain a special symbol that identifies the beginning of the address space of the process, i.e. this or my process address space. For example, the tests above may be able to use __bss_start on GCC. In general, we need to use the symbol that corresponds to the process that loads the library (and not the one corresponding to the PKCS#11 library). Thus, I believe that it's technically possible to write a PKCS#11 library that will inter-operate with a client, whether it's doing (1) or (2).

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]