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
> "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
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
> 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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk