- Remove namespace experimental.

- Create ESP.random functions in the core based on the defaultNonceGenerator code, and use these in defaultNonceGenerator.

- Rename CryptoInterface to esp8266::Crypto and move all functionality to the core.

- Remove need to #include <bearssl/bearssl.h> in the Crypto header file by changing br_hkdf_context to ::br_hkdf_context.

- Restyle code files for core usage.

cores/esp8266/Esp.cpp

@@ -522,6 +522,63 @@ bool EspClass::eraseConfig(void) {
     return true;
 }
 
+uint8_t *EspClass::random(uint8_t *resultArray, const size_t outputSizeBytes) const
+{
+  /**
+   * The ESP32 Technical Reference Manual v4.1 chapter 24 has the following to say about random number generation (no information found for ESP8266):
+   * 
+   * "When used correctly, every 32-bit value the system reads from the RNG_DATA_REG register of the random number generator is a true random number.
+   * These true random numbers are generated based on the noise in the Wi-Fi/BT RF system.
+   * When Wi-Fi and BT are disabled, the random number generator will give out pseudo-random numbers.
+   * 
+   * When Wi-Fi or BT is enabled, the random number generator is fed two bits of entropy every APB clock cycle (normally 80 MHz).
+   * Thus, for the maximum amount of entropy, it is advisable to read the random register at a maximum rate of 5 MHz.
+   * A data sample of 2 GB, read from the random number generator with Wi-Fi enabled and the random register read at 5 MHz,
+   * has been tested using the Dieharder Random Number Testsuite (version 3.31.1).
+   * The sample passed all tests."
+   * 
+   * Since ESP32 is the sequal to ESP8266 it is unlikely that the ESP8266 is able to generate random numbers more quickly than 5 MHz when run at a 80 MHz frequency.
+   * A maximum random number frequency of 0.5 MHz is used here to leave some margin for possibly inferior components in the ESP8266.
+   * It should be noted that the ESP8266 has no Bluetooth functionality, so turning the WiFi off is likely to cause RANDOM_REG32 to use pseudo-random numbers.
+   * 
+   * It is possible that yield() must be called on the ESP8266 to properly feed the hardware random number generator new bits, since there is only one processor core available. 
+   * However, no feeding requirements are mentioned in the ESP32 documentation, and using yield() could possibly cause extended delays during nonce generation.
+   * Thus only delayMicroseconds() is used below.
+   */ 
+
+  constexpr uint8_t cooldownMicros = 2;
+  static uint32_t lastCalledMicros = micros() - cooldownMicros;
+
+  uint32_t randomNumber = 0;
+
+  for(size_t byteIndex = 0; byteIndex < outputSizeBytes; ++byteIndex)
+  {
+    if(byteIndex % 4 == 0)
+    {
+      // Old random number has been used up (random number could be exactly 0, so we can't check for that)
+
+      uint32_t timeSinceLastCall = micros() - lastCalledMicros;
+      if(timeSinceLastCall < cooldownMicros)
+        delayMicroseconds(cooldownMicros - timeSinceLastCall);
+
+      randomNumber = RANDOM_REG32;
+      lastCalledMicros = micros();
+    }
+
+    resultArray[byteIndex] = randomNumber;
+    randomNumber >>= 8;
+  }
+
+  return resultArray;
+}
+
+uint32_t EspClass::random() const
+{
+  union { uint32_t b32; uint8_t b8[4]; } result;
+  random(result.b8, 4);
+  return result.b32;
+}
+
 uint32_t EspClass::getSketchSize() {
     static uint32_t result = 0;
     if (result)

cores/esp8266/Esp.h

@@ -164,6 +164,9 @@ class EspClass {
 
         bool eraseConfig();
 
+        uint8_t *random(uint8_t *resultArray, const size_t outputSizeBytes) const;
+        uint32_t random() const;
+
 #ifndef CORE_MOCK
         inline uint32_t getCycleCount() __attribute__((always_inline));
 #else