Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-05-10 15:33:03


Gerhard Wesp wrote:
> On Tue, May 09, 2006 at 11:03:02PM -0500, Rene Rivera wrote:
>> the proposals I've seen useless. There are two aspects which must be
>> addressed:
>
> "Useless" is a strong word.

But I think it applies. The problem with the crypto domain is that if
any single part is insecure the whole is insecure.

>> 1. Security of memory allocation.

> Should be solved on a memory management/OS level. Adding allocator
> parameters may be the way to go. But it may be easier to ask the OS to
> erase the memory once the process dies. Are there OSes that support
> this?

OpenBSD, which is what I run on my server :-), does that and also
supports encrypted pages. But having the OS handle it doesn't help C++
all that much. Since most stdlib implementations allocate from a larger
preallocated memory segment, the OS will never clear the small part you
would be using for the smaller bigint instance. Now you could just make
a bigint implementation that does additional work of clearing memory but
that will impact efficiency for other domains. Hence the need to provide
a way to control how the memory is maintained in a domain specific manner.

>> 2. Access to normalized representation.
> Define "normalized representation".

In this particular case, a representation that is compact but is not
necessarily the one used internally. Ideally it would be the one used
internally to minimize translation time. For integers this might be a 2s
complement array, and for floats it might be individual sign, exponent,
and mantissa as bigints (and hence as 2s complement arrays).

> I do think that the type should support all the conversions defined for
> the built-in types, including conversion to hexadecimal.

I can agree with that for symmetry. But at least in the crypto domain
conversion to built-in types would never be used. The logic goes... If
one is using a bigint one is expecting the number to not fit within any
built-in type, hence one would never convert to those types. That logic
is likely to apply to other domains, but since one wants conversion from
built-in types it seems reasonable to provide the other conversions.

>> required by certificates, keys, protocols, etc. So a documented access
>> to the representation is essential for implementing such translation
>> efficiently.
>
> Can you give an example of a translation that would require this access?

* SSH uses Base64 encoding to store keys. This is common as the most
compact representation is desired for transmittal through things like email.

* If one is implementing a key exchange protocol, for example I use a
Diffie Hellman key exchange
<http://en.wikipedia.org/wiki/Diffie-Hellman>, sending a binary
representation would be preferred to save on bandwidth.

The Java BigInt provides a toByteArray() conversion with a defined
representation <http://tinyurl.com/fghkk>, with a matching constructor.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk