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]