Live data from Hacker News

Convert standard Geiger counter to RNG

github.com

31–40 of 42 posts

Re: Convert standard Geiger counter to RNG

#31
post #6

Earlier quoted context omitted.

No this is all wrong. Fire crackles clearly depend on state. Nuclear decay is memoryless; decays are independent events. https://en.m.wikipedia.org/wiki/Radioactive_decay#Mathematic... > theoretical >12 sources What?

Thanks for the correction on nuclear state. It's hard to imagine anything having absolutely no state - but I guess a nucleus is not a "thing" as such, even if surrounded by lots of similar non-things. Does state not subsist in the total assembled mass in my example of near-critical collection?

Just answering myself after some reading today.

No, not really Because fission caused by free neutrons (which are rare) is something different from more common "spontaneous" radio-decay.

That does beg the question; what is the cause that we don't yet understand, what lies behind little bits of the universe falling apart?

Re: Convert standard Geiger counter to RNG

#32
post #28

Earlier quoted context omitted.

I don't understand what you mean by "leak" here. Again, not a crypto expert, but my understanding is that all stream ciphers leak some bits of the key with enough output. This is why differential cryptanalysis is possible against them. This is also why RC4 could be broken. EDIT: Perhaps a better algorithm: Accumulate 128 bits of entropy and use that to key Salsa20. Then, whenever another 128 bits are accumulated, sim…

It’s why RC4 is broken, not a thing we accept from ciphers that aren’t comically broken.

Isn't that a matter of degree? RC4 leaks a lot. "Acceptable" ciphers leak so little, it's still not feasible to break the full version. But apparently this scales with increasing or reducing rounds. So it seems unlikely it ever goes to zero. It just gets near enough to zero, that there are no feasible attacks for some length of message.

Re: Convert standard Geiger counter to RNG

#33

Earlier quoted context omitted.

I don't understand what you mean by "leak" here. Again, not a crypto expert, but my understanding is that all stream ciphers leak some bits of the key with enough output. This is why differential cryptanalysis is possible against them. This is also why RC4 could be broken. EDIT: Perhaps a better algorithm: Accumulate 128 bits of entropy and use that to key Salsa20. Then, whenever another 128 bits are accumulated, sim…

The term "stream cipher" is much more general than how you understand it. There is a huge number of stream ciphers that have never been broken. There is also a great number of stream ciphers that have been broken, but almost all of them belong to a class of ciphers that deserves the name "cheap stream ciphers". Such "cheap stream ciphers" have been designed so that they can have a much cheaper implementation than the…

The term "stream cipher" is much more general than how you understand it.

This strikes me as a non-sequitur? Could you provide me with a quote where I misunderstood the term "stream cipher" and how I misunderstood it?

There is a huge number of stream ciphers that have never been broken.

I understand this to mean, that the full version of the algorithm doesn't have any feasible attacks. That the difficulty of the known attacks is so high, there is virtually zero value to them over using brute force.

Based on how the encryption mask stream is generated, there are many kinds of stream ciphers

If you read the thread carefully enough, you can deduce which kind of stream cipher I was thinking of.

Re: Convert standard Geiger counter to RNG

#34
post #28

Earlier quoted context omitted.

It’s why RC4 is broken, not a thing we accept from ciphers that aren’t comically broken.

Isn't that a matter of degree? RC4 leaks a lot. "Acceptable" ciphers leak so little, it's still not feasible to break the full version. But apparently this scales with increasing or reducing rounds. So it seems unlikely it ever goes to zero. It just gets near enough to zero, that there are no feasible attacks for some length of message.

No, it's not. A reasonable cryptanalytical model of a modern stream cipher (AED in a stream mode, or Salsa20, or whatever) is that --- within the birthday bounds of the underlying cipher (exabytes? you'd look it up, whatever you're using), and, in the case of something like an AEAD (or maybe just in the idiosyncratic case of GCM), the bounds of your nonce width --- they're not leaking _anything_. "Comical" really is the right word to use with respect to what RC4 did. It is kind of amazing that a cipher that broken remained in common use for as long as it did.

Re: Convert standard Geiger counter to RNG

#35

Earlier quoted context omitted.

The term "stream cipher" is much more general than how you understand it. There is a huge number of stream ciphers that have never been broken. There is also a great number of stream ciphers that have been broken, but almost all of them belong to a class of ciphers that deserves the name "cheap stream ciphers". Such "cheap stream ciphers" have been designed so that they can have a much cheaper implementation than the…

The term "stream cipher" is much more general than how you understand it. This strikes me as a non-sequitur? Could you provide me with a quote where I misunderstood the term "stream cipher" and how I misunderstood it? There is a huge number of stream ciphers that have never been broken. I understand this to mean, that the full version of the algorithm doesn't have any feasible attacks. That the difficulty of the know…

I don't really follow the misunderstandings here, but on the off chance this re-level-sets the thread: you don't continuously inject new "entropy" (ie: rekey) a random bit generator out of concern that the underlying primitive is "leaking" (if it leaks, you fix the leak). Rather, you do so for post-compromise security, because there is basically no reason not to have some measure of post-compromise security such that if the state of your DRBG is compromised (by some systems vulnerability, not by cryptanalysis), in some relatively short interval security will be "restored" by rekeying.

I think that's pretty much it, the whole reason sophisticated CSPRNGs have entropy pools and stuff.

Re: Convert standard Geiger counter to RNG

#36
post #12

Have you tested how good the random numbers are? I think they should be good, if the interval between clicks is much larger than the interval for the counter, but I may be missing something. Also, some source emit two particles and I don't know if there are interesting cascades of decompositions. If two consecutive clicks are close enought, I expect an uneven distribution on increasing secuances like 13478AC023489BC.…

I'm assuming the source is just ordinary background radiation. I'm wondering if, at such low levels, the geiger counter can accurately determine it enough to get a truly random output (as opposed to, some internal squelch on the unit creating predictable patterns). You probably would get far better randomisation ripping out americium from an old smoke detector and putting it by the geiger counter. (Just take note tha…

Much safer to buy Uranium on Amazon. That’s what I did. It really freaks people out when you pull out a small metal can with a RADIOACTIVE sticker on it.

You can also get uranium glass beads and radioactive watch hands on Electronics Goldmine.

Re: Convert standard Geiger counter to RNG

#38

Earlier quoted context omitted.

The term "stream cipher" is much more general than how you understand it. There is a huge number of stream ciphers that have never been broken. There is also a great number of stream ciphers that have been broken, but almost all of them belong to a class of ciphers that deserves the name "cheap stream ciphers". Such "cheap stream ciphers" have been designed so that they can have a much cheaper implementation than the…

The term "stream cipher" is much more general than how you understand it. This strikes me as a non-sequitur? Could you provide me with a quote where I misunderstood the term "stream cipher" and how I misunderstood it? There is a huge number of stream ciphers that have never been broken. I understand this to mean, that the full version of the algorithm doesn't have any feasible attacks. That the difficulty of the know…

I quote here what you have said:

"my understanding is that all stream ciphers leak some bits of the key with enough output"

This is a false statement.

Nowadays, the most frequently used encryption method is to use a stream cipher (more precisely a binary additive synchronous stream cipher), where the automaton that generates the encryption mask stream is implemented with a counter and with an output function that is an unpredictable pseudorandom function, usually either AES or ChaCha20.

With an appropriate pseudorandom function, such a stream cipher does not leak any bits of the key, even with enough output. There are methods of breaking a cipher with enough computation and memory, but those are specific to the pseudorandom function that happens to be used and they are not limited to stream ciphers, they are equally applicable to block ciphers that use the same pseudorandom function. Moreover, the known methods used to construct block ciphers are usually easier to break than good stream ciphers that use the same pseudorandom function.

It is obvious that when you have written "all stream ciphers", what you had in mind were not "all" such ciphers, but certain stream ciphers with very low implementation cost, but also with inadequate strength, which have been specified in many older communication protocols, e.g. in those for mobile phones (because the communication equipment manufacturers only cared about a low production cost, not about security, and the so-called encryption was only added to fool the customers, not to prevent professional attacks). Such cheap stream ciphers have been easily broken by anyone who has studied them seriously.

The ciphers that you have designated by "all stream ciphers" are an extremely small fraction of what is meant by "all stream ciphers" in the cryptographic literature, as I have explained in my previous post.

Your confusion might have been increased by hearing people referring to AES as being a "block cipher". That is very wrong, because AES is not a block cipher. It is not even a cipher. AES is an unpredictable pseudorandom function, which maps an encryption key and an input symbol to an output symbol. Alternatively, AES can be viewed as a parametrized family of bijective functions (a.k.a. invertible functions), where each of the bijective functions is identified by a parameter that is the encryption key.

With an unpredictable pseudorandom function, it is possible to build various kinds of ciphers, either block ciphers or stream ciphers. Nowadays it is much more frequent to use stream ciphers based on AES, than block ciphers based on AES.

General disadvantages of the block ciphers are that the message must be padded to a multiple of the block length and that both the direct and the inverse forms of the invertible pseudorandom function are required to be implemented.

In the past, because authenticated encryption was not used, block ciphers (e.g. the so-called CBC mode) were preferred, because they made difficult the tampering of the message by amateurs, even if, in the absence of authentication, they had little chances to stop a professional attacker.

After the use of authentication has become ubiquitous, the stream ciphers have become preferable for most applications, even if there remain a few niches where block ciphers have advantages.

Re: Convert standard Geiger counter to RNG

#40

Earlier quoted context omitted.

The term "stream cipher" is much more general than how you understand it. This strikes me as a non-sequitur? Could you provide me with a quote where I misunderstood the term "stream cipher" and how I misunderstood it? There is a huge number of stream ciphers that have never been broken. I understand this to mean, that the full version of the algorithm doesn't have any feasible attacks. That the difficulty of the know…

I quote here what you have said: "my understanding is that all stream ciphers leak some bits of the key with enough output" This is a false statement. Nowadays, the most frequently used encryption method is to use a stream cipher (more precisely a binary additive synchronous stream cipher), where the automaton that generates the encryption mask stream is implemented with a counter and with an output function that is…

There are methods of breaking a cipher with enough computation and memory, but those are specific to the pseudorandom function that happens to be used

But doesn't this constitute leakage of the algorithm's internal state in the output? (Albeit, very slow.)

and they are not limited to stream ciphers

I never said any of the above was limited to stream ciphers.

Post reply on HN