This adds support for encrypted ONC import

crypto/hmac.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "crypto/hmac.h"
 
 #include <algorithm>
 
 #include "base/logging.h"
 #include "crypto/secure_util.h"
+#include "crypto/symmetric_key.h"
 
 namespace crypto {
 
+bool HMAC::Init(SymmetricKey* key) {
+  std::string raw_key;
+  bool result = key->GetRawKey(&raw_key) && Init(raw_key);
+  // Zero out key copy.  This probably just gets optimized away,

[kmixter1, 2012/01/05 23:27:53]

I don't think the stuff after fill will have any effect.  If you really want to
be sure that the clearing is not optimized away, instead do this:

volatile char* heap_pointer = raw_key.data();
memset(heap_pointer, 0, raw_key.size());
return result;

Then you've created an aliasing pointer to volatile memory whose accesses by
memset could never be optimized away.

That's all theoretical.  I don't think a compiler exists that does enough heap
analysis to remove write heap accesses before free's, even in C much less
through all the spaghetti of C++ stl functions. :)

[Greg Spencer (Chromium), 2012/01/05 23:41:06]

OK, I'll do that.  Why is mine different (other than order)?  Seems like the
compiler couldn't assume that the raw_key was not accessed if we access it and
assign to a volatile.  Is it the use of c_str() instead of data()?

[kmixter1, 2012/01/06 17:55:59]

I was trying to use data() to get at the actual internal representation of the
string, but unfortunately the standard doesn't guarantee it is (and c_str()
definitely isn't as some implementations don't NULL terminate the string
internally).  Using data() as I did is wrong though as the spec says that you
must not write to the pointer returned from it.

So anyway, I don't think the existing code accomplishes avoiding an
optimization, but compilers don't do this so it's probably not worth the thought
exercise of how to do it.

+  // but one can hope.  Using std::string to store key info at all is a larger
+  // problem.
+  std::fill(raw_key.begin(), raw_key.end(), 0);
+  // Trying to keep the call above from being optimized away by assigning info
+  // from the object to a volatile.
+  volatile char *optimization_blocker = const_cast<char*>(raw_key.c_str());
+  optimization_blocker = NULL;
+  return result;
+}
+
 size_t HMAC::DigestLength() const {
   switch (hash_alg_) {
     case SHA1:
       return 20;
     case SHA256:
       return 32;
     default:
       NOTREACHED();
       return 0;
   }
@@ skipping 14 matching lines @@
   scoped_array<unsigned char> computed_digest(
       new unsigned char[digest_length]);
   if (!Sign(data, computed_digest.get(), static_cast<int>(digest_length)))
     return false;
 
   return SecureMemEqual(digest.data(), computed_digest.get(),
                         std::min(digest.size(), digest_length));
 }
 
 }  // namespace crypto