At 01:27 AM 4/28/2007, you wrote:
>the "Weak"
>namespace is automatically imported into the main "CryptoPP" namespace by a
>"using" directive along with a #warning if you #include one of the header
>files containing a weak algorithm.
[... more omitted ...]
>Does this solution seem good enough?
That method does seem adequate for the original problem statement. Some
minor points:
1) I'd make use #error and not #warning. It would tend to force an
important issue higher up into an organization, where that context applies.
2) I'd use #define's to enable algorithms each-by-each. Each such line
provides documentation about how it's insecure, not just that it's insecure.
On the other hand, there are other use cases for temporal security
guarantees, more than those directed at compile-time. Consider the
following skeleton use case:
-- An experimental protocol uses algorithm negotiation. On the grounds of
efficiency or stubborn 1334-ness, the default algorithm is of unknown
security. The makers know this and provide a fallback, but would like to
automatically take it out of the first position in negotiation if it's
later found to be weak. The authors don't want to be security authorities
themselves and would like to rely on new releases of Crypto++ for that
information flow.
I'm sure there are more use case similar to this. The common thread is
programmatic manipulation, at run-time, of security guarantees. So, if
this class of use cases is desirable, the namespace trick can't work,
because namespaces don't use infrastructure that can be made visible at
run-time.
I believe this class of solutions is desirable, and for a pretty basic
reason. Namely, I don't believe it's possible to do a best-effort job of
security policy about crypto unless the issue of algorithm change is
addressed. The use case I outlined above illustrates this generic concern.
Specifically, what I would recommend as the technical basis for this
solution is a system of "algorithm_traits". This is an exact analogue to
"std::char_traits" that the standard library uses for strings. The same
technique is used in "std::numeric_limits". (This technique has wider
applicability than security guarantees, in addition.) The general
declaration would be thus:
template< class Alg > struct algorithm_traits{} ;
A specific declaration might be something like this:
template<> struct algorithm_traits< MD4 > {
static const algorithm_type = Hash ;
static const Hash_Result_Size = 128 ;
static const int Year_Deprecated = 1991 ;
static const int Year_Broken = 1996 ;
}
It seems clear that this mode of capturing information can be used to
perform conditional compilation, to meet the needs of the original question.
So, my question is this: Do you want to support an expanded requirement to
enable run-time as well as compile-time use cases? If you do, I have more
thoughts about additional desiderata.
Eric
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
