BIND 10 #781: Define cryptographic API

[BIND 10 Development]

#781: Define cryptographic API
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20110503
  blocker                            |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:27 jinmei]:
 > Looking at it more closely, and based on the observation that hash
 > algorithms are not specific to HMAC (for example, we may want to
 > replace our homemade sha1 implementation using this framework, or we
 > may want to integrate it to this framework), I'd suggest moving
 > HashAlgorithm to hmaclink.h (or a separate crypto_hash.h or
 > something).  Then, in cryptolink.h, we can only put a forward
 > declaration of 'class HMAC' and avoid including crypto_hmac.h.
 >

 I've moved it up to cryptolink.h; if we do decide to implement hashes
 through this it should probably be moved there then, but as a general
 identifier list it also fits directly in the main link header imo. I did
 rename UNKNOWN to UNKNOWN_HASH for clarity.

 > Whether or not we use function-based friend (on which I don't have a
 > strong opinion) I think this is a good change.
 >

 Well now that this has been cleaned up i see no reason to declare all of
 CryptoLink friend, so i've changed this too.

 > And (yet) another point I noticed while I was looking at the code: it
 > looks possible to change the return value of
 > CryptoLink::getCryptoLink() to 'const CryptoLink&' (and then we have
 > to change CryptoLink::createHMAC() a const member function).
 >

 It can, the question is, should it? It kind of depends on what you
 consider that CryptoLink instance to be; createHMAC could be const, but in
 a way such factory functions do modify the instance (since the backend
 does some internal memory management, again the question being do we
 consider that state of the cryptolink object). But it's a minor change so
 if you insist on it i can add it quickly :)

-- 
Ticket URL: <http://bind10.isc.org/ticket/781#comment:31>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development