Sigh.
wrote:
Let's first imagine I'm supposed to write a program that's generating cyphers to generate a certificate, or a blockchain.
Stop right there, and get a professional cryptographer. Or, better, get a professional cryptographic engineer, who can implement a standard cryptosystem with standard, vetted ciphers and other cryptographic primitives, with meaningful security guarantees under an explicit threat model that's relevant to the actual use case.
COBOL's RANDOM intrinsic function is not a cryptographic pseudorandom number generator, and using it for any cryptographic purpose is an extremely bad idea.
Or, better, some winning numbers. An official lottery program perhaps.
An even worse idea.
The program to write has to pass the revision dept.'s judgement of generating new, unique, "true" random numbers whenever it's called, no matter how often or at which time of day.
You're Doing It Wrong.
You wrote that "all (settable) bits of the seed value should affect the sequence".
So, you suggest that if I declared the seed value to be, for instance, PIC 9(50) USAGE IS DISPLAY,
That's not a valid "numeric-class elementary data item", as I also specified.
which is an amazingly large number range, like this:
No, it's an error. (As for what constitutes "amazingly large" ... a 50-decimal-digit number has less than 161 bits of entropy. In crypto we eat that sort of thing for breakfast.)
This COBOL tutorial document claims that, no matter how large the seed value is declared, only the rightmost 31 bitswill be considered for calculating the seed value.
That COBOL tutorial document does not determine the behavior of Micro Focus COBOL.
That's quite a huge difference in result, because if I used a seed value large enough to hold more than 31 bits, and if I incidentally provided values only varying in the MSBs "left to" these significant 31 LSBs, then I wouldn't get random sequences at all.
Well, it's a "huge difference" mostly because one of those cases is an error. But yes, obviously, if you could specify a seed larger than the internal state of the PRNG, then it's possible (though not necessary) that some bits of the seed would not affect the PRNG's internal state.
(Why not necessary? Because the PRNG could hash all the [significant] bits of the seed so that they all contributed some nonzero amount of information entropy to the state, or by updating the internal state with bits or blocks of an arbitrarily-long seed stream, which comes to the same thing. A PRNG is not forced to discard seed entropy beyond the size of its state, though of course the total entropy of the PRNG is restricted to the size of the state, so by the pigeonhole principle there are an infinite number of equivalent seeds for at least one state.)
That's why I believe it's important to know the range of digits (or values) accepted by the seed value.
I understand why you think that. I've explained what's guaranteed by the system, and anything beyond that is an internal implementation detail.
It's also important to know if a hash function is getting applied to the provided seed value to shorten its accepted range. If, for instance, a plain FUNCTION MOD would be getting applied, risk is high that attackers easily might predict future random sequences.
Your threat model isn't entirely clear to me, but it certainly sounds like you're using the RANDOM intrinsic for something inappropriate.
Nonetheless, the answer to this (implied) question is present in my previous post. The seed must be a non-negative numeric-class elementary data item. If it is, then all bits affect the internal state of the PRNG.
For Micro Focus COBOL, that means 64 bits; that's the maximum size of (the internal representation of) a numeric-class elementary data item.
"Out of curiosity, what difference do you posit between "high and low" bits, on the one hand, and "left and right" bits on the other?"
The difference was that "high and low" dealt with bits (binary system) while "left and right" dealt with digits (decimal system).
Ah, I see. While that's certainly an interesting nomenclature you have there, you might want to be a bit more explicit in the future. And, perhaps, don't immediately jump to the conclusion that you know more about the subject than your interlocutors do. Just a suggestion.
I might point out that there is a vast collection of PRNGs, suited for different use cases, available as open source, in libraries, and so on. If you need particular parameterizations, distributions, behavorial guarantees, security guarantees, or what have you, then you'd do well to pick one that explicitly provides those attributes. You can't swing a seed value without hitting an implementation of some Mersenne Twister variant. It wouldn't be hard to implement a CMWC generator even in COBOL. You could use an entropy pool and iterated HMAC or a PBKDF, depending on the details of your use case (or, though this is still cause for concern, your threat model). Rather than worry about what the RANDOM intrinsic provides beyond what the Standard specifies, use a generator that gives you what you think you want.
