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