Encapsulate SecureZeroData in a type

[darkdh]

Encapsulate SecureZeroData in a type

[darkdh]

I think unique_ptr deleter approach has the same fragile level. We used to have that then it got refactored out.
A dedicated type or template is the way to go.

[darkdh]

Ah I forgot it was not moved out, it is changed to actually using alias SecureVector with SecureZeroAllocator as
using SecureVector = std::vector<uint8_t, SecureZeroAllocator<uint8_t>>
and

// Allocator which will zero out memory when destruct
template <typename T>
struct SecureZeroAllocator {
  SecureZeroAllocator() = default;
  ~SecureZeroAllocator() = default;
  SecureZeroAllocator(const SecureZeroAllocator&) = default;
  SecureZeroAllocator& operator=(const SecureZeroAllocator&) = default;
  SecureZeroAllocator(SecureZeroAllocator&&) = default;
  SecureZeroAllocator& operator=(SecureZeroAllocator&&) = default;

  using value_type = T;
  T* allocate(size_t n) {
    return static_cast<T*>(::operator new(n * sizeof(T)));
  }
  void deallocate(T* p, size_t n) {
    SecureZeroData(p, n);
    ::operator delete(p);
  }
};

[bridiver]

for cases like this where we're calling a third party method I think it would be useful to limit direct access to the third party lib (visibility and DEPS) and wrap it something that enforces zero on deletion

std::unique_ptr<HDKey> HDKey::GenerateFromExtendedKey(const std::string& key) {
  std::vector<unsigned char> decoded_key(kSerializationLength);
  if (!DecodeBase58Check(key, decoded_key, decoded_key.size())) {
    LOG(ERROR) << __func__ << ": DecodeBase58Check failed";
    return nullptr;
  }

  SecureVector buf(decoded_key.begin(), decoded_key.end());
  SecureZeroData(decoded_key.data(), decoded_key.size());