[Botan-devel] Key management issue
balasn at gmail.com
Tue Apr 14 15:38:52 EDT 2009
Thanks Jack. I think you may have forgotten the attachment with the fixes. I
appreciate the help.
On Tue, Apr 14, 2009 at 12:34 PM, Jack Lloyd <lloyd at randombit.net> wrote:
> On Tue, Apr 14, 2009 at 11:27:22AM -0700, Bala Narasimhan wrote:
> > Below is a test program I wrote up with Botan. The idea is as follows:
> > (1) Parent process P1 creates an mmap'ed region in SHARED mode.
> > (2) It creates a bunch of SymmetricKeys and InitializationVectors and
> > them into the region created in (1) above.
> > (3) The child process tries to interpret the values stored by the parent.
> > (3) fails. When I print out as_string() in the context of the child I get
> > bunch of zeroes. This is in contrast to the parent when if I print out
> > as_string() representation of the keys I get what seem like sane values.
> > Can someone tell me what I am doing wrong? I appreciate the help.
> Ah, here is where things go off, I think:
> > SymmetricKey *k = (SymmetricKey *) new(sharedmem)
> > InitializationVector *v = (InitializationVector *) new(k + 1)
> > SymmetricKey *k = (SymmetricKey *)sharedmem;
> > InitializationVector *v = (InitializationVector *)(k+1);
> The placement new operator will allocate the SymmetricKey and
> InitializationVector objects in the shared memory, but the key data
> itself is stored in a SecureVector<byte>, which is a member variable
> of the SymmetricKey/InitializationVector. The memory contents of this
> type are allocated seperately. So in Decrypt, the lengths match since
> those are saved to the shared memory, as are the pointer values, but
> in Decrypt() these pointers point to nothing meaningful (which you can
> check by running your test case under valgrind, which shows invalid
> reads in Decrypt).
> I've attached a modified version of your testcase that copies the key
> and iv bits to the shared memory using a very simple length+contents
> format. This code prints the same key/iv in both parent and child. It
> or something like it probably sufficies if you're just passing these
> two values, if it turns out you're going to be doing much more I'd
> recommend using ASN.1 or some other structured format, since passing
> values through untyped memory in this way can be quite error prone.
> botan-devel mailing list
> botan-devel at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the botan-devel