Tjyylli

I have written the following random numbers generator. I would like to know how safe this is and if it is suitable for use in computer engineering. For me, the result looks very random, but would like to have several opinions on it.

#!/usr/bin/env python

# -*- coding: utf-8 -*-



import os

import fcntl

import struct

import logging

import json

import urllib

import time

from decimal import Decimal

import datetime

import hashlib



LOG_FILENAME = 'entro.py.log'

formatter = logging.Formatter('[%(asctime)s] %(levelno)s (%(process)d) %(module)s: %(message)s')

fh = logging.FileHandler(LOG_FILENAME)

fh.setLevel(logging.DEBUG)

fh.setFormatter(formatter)

logger = logging.getLogger('MyLogger')

logger.setLevel(logging.DEBUG)

logger.addHandler(fh)

debug = logger.debug

info = logger.info

warning = logger.warning

error = logger.error

critical = logger.critical





def add_entropy(rnd):

    """ Add data to the entropy pool """

    """ From https://github.com/netom/onetimepad/blob/master/rndaddentropy.py """

    info('Add to entropy')

    fd = os.open("/dev/random", os.O_WRONLY)

    # struct rand_pool_info {

    # int entropy_count;

    # int buf_size;

    # __u32 buf[0];

    # };

    fmt = 'ii%is' % len(rnd)

    # Here we set 6*len(rnd) entropy bits (instead of 8 because tweet data does not have perfect randomness)

    rand_pool_info = struct.pack(fmt, 6 * len(rnd), len(rnd), rnd)

    fcntl.ioctl(fd, 1074287107, rand_pool_info)

    os.close(fd)

    info('added to entropy')



def get_JSON_ticker(url="https://blockchain.info/ticker"):

    info("Load data from %s" % url)

    response = urllib.urlopen(url)

    Data = json.loads(response.read())

    return Data



def main():

    info('The tool to add Entropy to the system is started.')

    start = datetime.datetime.now()

    BTC_Exc_Data = get_JSON_ticker()

    summe = 0

    for currency in BTC_Exc_Data:

        summe += float(BTC_Exc_Data[currency]["last"])

    summe = Decimal(summe) * Decimal(time.time())

    end = datetime.datetime.now()

    diff = end - start

    d = Decimal(summe)*Decimal(diff.microseconds)

    Text = str(d)

    Text = Text.replace("00", "").replace(".", "")

    Text2 = hashlib.sha512(Text).hexdigest() + hashlib.sha256(Text).hexdigest() + hashlib.sha1(Text).hexdigest() + hashlib.sha224(Text).hexdigest() + hashlib.sha384(Text).hexdigest()

    Text = str(diff.microseconds**diff.microseconds)

    Text = hashlib.sha512(Text).hexdigest() + hashlib.sha256(Text).hexdigest() + hashlib.sha1(Text).hexdigest() + hashlib.sha224(Text).hexdigest() + hashlib.sha384(Text).hexdigest()

    Text += Text2

    debug("entropy string has a size of %s" % str(len(Text)))

    add_entropy(Text)



    info('The tool to add Entropy to the system has finished.')







if __name__ == '__main__':

    main()

There are a few things going on in your approach that need to be discussed, so let's look at each of those individually, and then see if we can come to a conclusion about your design.

Seeding /dev/random

There is certainly nothing wrong with reseeding /dev/random just as long as you understand the Linux CSPRNG architecture. When sending data to the kernel's CSPRNG, the data is mixed in the input pool with other data collected by the system. In fact, the kernel is mixing hardware events and interrupts into the input pool consistently, and this really only becomes a problem for embedded, low power, solid state devices where hardware interrupts are rare.

After data is added to the input pool, it is then mixed with all the other data in the input pool with a randomness extractor. The goal of this mixing is to take correlated, biased, and predictable data, and extract the raw entropy. Once extracted, that data is then encrypted with ChaCha20, if using Linux 4.8+, or SHA-1 otherwise (MD5 if you're using a really early 1.x or 2.x kernel).

Sending data from publicly accessible data, like Bitcoin transactions, into the CSPRNG to reseed it is fine, but don't get any false sense of security. You won't degrade the security margins of the generator, but you may not increase the security margins of the generator either. Ultimately, the goal of reseeding a CSPRNG is to prevent backtracking attacks, which you can't do with public data. So let's talk about that next.

Backtracking resistance

You're using SHA-512 as a randomness extractor, and that's perfectly fine, but as it stands in your implementation, it's not enough. SHA-512 is designed to take biased, correlated bits, and turn it into a fixed-length output of statistically unbiased, uncorrelated bits.

This is simple enough to demonstrate in the terminal:

$ dd if=/dev/zero bs=1 count=1000 2> /dev/random | sha512sum

ca3dff61bb23477aa6087b27508264a6f9126ee3a004f53cb8db942ed345f2f2d229b4b59c859220a1cf1913f34248e3803bab650e849a3d9a709edc09ae4a76  -

Here we fed 1,000 bytes of binary zeros into SHA-512, and got an output that is a hexadecimal representation of those unbiased bits. So, if SHA-512 is reseeded with unique, and secret seeds, then its output in indistinguishable from true random white noise, and it's data is also unpredictable.

But not predicting future data isn't enough for a CSPRNG. We also need to design it such that we cannot reproduce past states, thus predicting previously calculated keys or secrets. This is called forward secrecy or backtracking resistance.

To illustrate this is very simple terms, consider a simple counter i=0, 1, 2, 3, ..., n. We could hash this with SHA-512, and it would produce unique statistically uniform independent bits. But suppose an adversary is able to compromise the state of the generator, and after watching the state, knows you're just incrementing a counter. All the adversary needs to do at this point is decrement the counter, and they can calculate all prior RNG states. This generator is not backtracking resistant.

Using time has a similar problem. What prevents the adversary from calculating past times in microseconds, and generating past states? Sure, there will be some variability in accuracy, but if the adversary can monitor the state of the generator, then the adversary knows how long it takes each state to execute. This gives a window with a small epsilon of past states to calculate.

Because your RNG is reliant on time, it's not backtracking resistant, and as such, not cryptographically secure.

Public vs secret seeds

Finally, there is a time and place where seeding a generator with public data is perfectly acceptable, primarily for audits and transparent verification. That is what randomness beacons, such as the ones by NIST and CLCERT are doing. But the goal of these beacons/generators is to provide accountability for social decisions, such as elections, sampling, drug testing, and other things, where people picked as a result of the generator, can force an audit on the decision, and it can be strongly proven they were picked uniformly, and without bias.

Generally though, for RNGs, we want secret seeds, because we want the output of the generator to be unpredictable. If the seed is public, then all future output can be calculated in advance. If the seed is secret, then predicting future output should be as difficult as either breaking the algorithm, or forcing discovery of the seed.

This is why you don't want to use random.org, Bitcoin, tweets, atmospheric noise, RF spectrum, or any other publicly accessible sources for seeds to RNGs. Because if an adversary can either influence the source (RF jamming) or read the source (Bitcoin), then they can use that knowledge to predict the outcome of your RNG.

Also, financial exchanges do not exhibit random walks. So as an entropy input, they're not very good. This includes Bitcoin markets and transactions.

A suggestion for improvement

First and foremost, you should only ever use /dev/urandom when you need secure and safe random numbers. Userspace RNGs are loaded with footguns, a couple of which I outlined here. They're also almost completely unnecessary. It really is the only place as a developer you should be turning, when you need cryptographically secure randomness.

However, if you're hell-bent on shipping a userspace RNG, then as a suggestion to improve the quality of your generator, I would suggest you turn to fast key erasure as explained by Dr. Daniel J. Bernstein. Drop SHA-512 in favor of keyed AES-128 and forget about Bitcoin and timestamps, but instead use 128-bits of secret theoretic entropy (flip a coin 128 times, roll a d6 50 times, Argon2id a password, etc) as your seed.