flat assembler
Message board for the users of flat assembler.

Index > Windows > How to generate random numbers?

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
macomics



Joined: 26 Jan 2021
Posts: 649
Location: Russia
macomics
To use this instruction, you will have to do a few more actions.
Code:
    mov     eax, 1
    cpuid
    test    ecx, 1 shl 30
    jz      unsupported
    mov     rcx, 1000000
try_loop:   rdrand rax
    sbb     dl, dl
    loopz   try_loop
    jrcxz   error_no_value    


Quote:
RDRAND - Loads a hardware generated random value and store it in the destination register. The size of the random value is
determined by the destination register size and operating mode. The Carry Flag indicates whether a random value
is available at the time the instruction is executed. CF=1 indicates that the data in the destination is valid. Other-
wise CF=0 and the data in the destination operand will be returned as zeros for the specified width. All other flags
are forced to 0 in either situation. Software must check the state of CF=1 for determining if a valid random value
has been returned, otherwise it is expected to loop and retry execution of RDRAND (see Intel® 64 and IA-32 Archi-
tectures Software Developer’s Manual, Volume 1, Section 7.3.17, “Random Number Generator Instructions”).
This instruction is available at all privilege levels.
In 64-bit mode, the instruction's default operation size is 32 bits. Using a REX prefix in the form of REX.B permits
access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bit oper-
ands. See the summary chart at the beginning of this section for encoding data and limits.
Quote:
RDSEED - Loads a hardware generated random value and store it in the destination register. The random value is generated
from an Enhanced NRBG (Non Deterministic Random Bit Generator) that is compliant to NIST SP800-90B and NIST
SP800-90C in the XOR construction mode. The size of the random value is determined by the destination register
size and operating mode. The Carry Flag indicates whether a random value is available at the time the instruction
is executed. CF=1 indicates that the data in the destination is valid. Otherwise CF=0 and the data in the destination
operand will be returned as zeros for the specified width. All other flags are forced to 0 in either situation. Software
must check the state of CF=1 for determining if a valid random seed value has been returned, otherwise it is
expected to loop and retry execution of RDSEED (see Section 1.2).
The RDSEED instruction is available at all privilege levels. The RDSEED instruction executes normally either inside
or outside a transaction region.
In 64-bit mode, the instruction's default operation size is 32 bits. Using a REX prefix in the form of REX.B permits
access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bit oper-
ands. See the summary chart at the beginning of this section for encoding data and limits.
Quote:
7.3.17 Random Number Generator Instructions
The instructions for generating random numbers to comply with NIST SP800-90A, SP800-90B, and SP800-90C
standards are described in this section.
7.3.17.1 RDRAND
The RDRAND instruction returns a random number. All Intel processors that support the RDRAND instruction indi-
cate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1.
RDRAND returns random numbers that are supplied by a cryptographically secure, deterministic random bit gener-
ator DRBG. The DRBG is designed to meet the NIST SP 800-90A standard. The DRBG is re-seeded frequently from
an on-chip non-deterministic entropy source to guarantee data returned by RDRAND is statistically uniform, non-
periodic and non-deterministic.
...
Code:
----------------------------------------------------------------------------------------
#define SUCCESS 1
#define RETRY_LIMIT_EXCEEDED 0
#define RETRY_LIMIT 10
int get_random_64( unsigned __int64 * arand)
{
  int i ;
  for ( i = 0; i < RETRY_LIMIT; i++) {
    if(_rdrand64_step(arand) ) return SUCCESS;
  }
  return RETRY_LIMIT_EXCEEDED;
}
-------------------------------------------------------------------------------    
Post 28 May 2022, 18:16
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1462
Location: Toronto, Canada
AsmGuru62
If it is hardware generated -- why does it need RDSEED?
Post 28 May 2022, 22:41
View user's profile Send private message Send e-mail Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3464
Location: vpcmipstrm
bitRAKE
The purpose of RDSEED is to get a value for a wider/faster software generator.
(It doesn't seem weird to anyone else that this instruction links all the cores together - for random data?)

_________________
¯\(°_o)/¯ unlicense.org
Post 29 May 2022, 00:46
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1462
Location: Toronto, Canada
AsmGuru62
Once, long ago (end of 80s) I was involved in something like this:

https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11022/2522433/Robust-random-number-generator-based-on-field-effect-transistor/10.1117/12.2522433.short?SSO=1

Not sure if our device was exactly on the same principle, that described in the link.
But it would start generating as soon as power is on. No seeds of any kind -- truly random.
I was writing a self test routine for it.
It was fun!

I think that this instruction does not do something like that.
If it wants a seed, then it is pseudo-random.
Post 29 May 2022, 01:20
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
Intel states that rdrand is a PRNG with a "special" circuit for seeding.

And therein lies the problem. They never publish the seeds, or the method of seeding. So there is no way to verify the seed is really random. It might be using an LCG with period 2^60. Impossible for anyone not aware of the internals to reverse, but "easy" for the NSA to spin through all 2^60 seeds to find the one you used to generate your LUKS key.


Last edited by revolution on 29 May 2022, 06:29; edited 1 time in total
Post 29 May 2022, 01:32
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3464
Location: vpcmipstrm
bitRAKE
I'm not seeing many random bit generators in the GHz range (excluding optical/laser methods). Most of them feed random bits into a wider algorithmic hardware generator - like Intel's design.

RDRAND & RDSEED performance is drastically different between Intel/AMD. They are clearly doing completely different things under the hood.

I would argue that RDSEED should be slow. The nature of the instruction is such that the intent is strictly for initialization of software techniques. Whereas RDRAND is intended as a PRNG on it's own. AMD's timings bear this out. Neither is a replacement for software methods.

_________________
¯\(°_o)/¯ unlicense.org
Post 29 May 2022, 02:09
View user's profile Send private message Visit poster's website Reply with quote
Ali.Z



Joined: 08 Jan 2018
Posts: 526
Ali.Z
I use Park-Miller PRNG.

_________________
Asm For Wise Humans
Post 29 May 2022, 14:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
Ali.Z wrote:
I use Park-Miller PRNG.
https://en.wikipedia.org/wiki/Lehmer_random_number_generator
Quote:
The Lehmer random number generator (named after D. H. Lehmer), sometimes also referred to as the Park–Miller random number generator (after Stephen K. Park and Keith W. Miller), is a type of linear congruential generator (LCG) that operates in multiplicative group of integers modulo n.
Post 29 May 2022, 14:57
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 575
Location: Ukraine
Overclick
Quote:

And therein lies the problem.

Is it big deal to modify the result at your own? Who know what did you made with it? Shift bits for example, replace bytes, etc
Post 29 May 2022, 15:13
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
Overclick wrote:
Quote:

And therein lies the problem.

Is it big deal to modify the result at your own? Who know what did you made with it? Shift bits for example, replace bytes, etc
It is no problem at all. And people do it because they don't trust rdrand. But doing those types of manipulations doesn't improve the security or the randomness. It is one of those feel-good things that doesn't actually have any real effect.

Many libraries will mix in seeding data from rdrand/rdseed but they won't adjust the entropy value to indicate it made things better.

The mistrust runs deep in the security folk. And rightly so. Too many times it has been shown how large corps have introduced intentional backdoors.
Post 29 May 2022, 15:26
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 575
Location: Ukraine
Overclick
Quote:

the security or the randomness.

You are assembly programmer, how can you believe those conspiracy theories?
1) You have to manage the result of random anyway, I mean size, symbols,markers. Especially where used for security purpose like random security keys. It never ready to use, it have to be prepared and only god knows how exactly you wish to do it.
2) How they develop hardware even if it can be patched? By years? Years of developing to finally guess what exactly OS, security protocols and purpose of use is? What if I use that random to switch a snow on my screen? Who or what AI have to analyse that tons of useless data? Is all of that POWER just wasting my processor space or it sends the data by somehow by hack my unknown OS its drivers and its network settings? WOW...
3) Concurrency? F..k it, we need more space for our conspiracy logic.

I did read that conspiracy theories too. Its funny, nothing else.
Post 30 May 2022, 11:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
Overclick wrote:
... conspiracy theories too. Its funny, nothing else.
Sometimes these things are real.
NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm.
Post 30 May 2022, 11:58
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 575
Location: Ukraine
Overclick
Cryptography library is most funny think in modern world. Who use it? Those guys just know nothing about programming that why they need to trust somebody for their protection. They use it as it is and hope nobody rob them. Similar to use cracked soft and hope there is no trojan on it.
But back to CPU instruction, it is absolute different thing. You don't ask CPU to create some trusted keys or crypt your secrets. It just provide some sort of random trash you have to configure for own purpose.
Post 30 May 2022, 16:13
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
Overclick wrote:
But back to CPU instruction, it is absolute different thing. You don't ask CPU to create some trusted keys or crypt your secrets. It just provide some sort of random trash you have to configure for own purpose.
For a cryptographer it is always assumed all code and algorithms are known to all parties. So doing basic bit-swizzling on values from rdrand does nothing for you, because all those operations can be trivially reversed to recreate the original value.

The only possible solution is to use real random data that can be trusted. Since rdrand has secret internal components that Intel/AMD won't reveal then they are automatically not trusted. Intel/AMD might be creating real true randomness, but no one can verify it so it might as well not exist in the cryptographers mind.

It's just the way they do things. You get caught with your pants down once, and you learn to lock the door next time.
Post 30 May 2022, 16:51
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 575
Location: Ukraine
Overclick
Cryptography doesn't need randomisation at all. It needs algorithm to convert something to and back. You may create the random key or not, it is up to you. You have to save it anyway. And why do you believe the key is leak by CPU directly? Why you use the key as some solid block or trust some libraries for processing? You want to be caught with pants down?

But, back to Randomiser, we talk about random numbers. Pure numbers, provided by CPU for unknown purpose. And I don't see ANY risks of that. But you talk about long chain of conspiracy, too long:
1) Prepare the cryptography soft by one side. Exact step by step for triggered instruction.
2) Prepare instruction inside CPU by dealing with huge corporacy (intel/amd/both) That instruction have to understand all of that steps at (1). Step left or step right and all conspiracy plan is wasted )))
The question: why plan (1) cannot completely do all dirty job? Why it needs that big preparation? Usually it does, as happen in your example.
Post 30 May 2022, 18:00
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
The bedrock of cryptography is having good random numbers. So to say it isn't necessary is really bad. Without randomness cryptography isn't possible. All you end up with is encoding and transformations, and no security.

Anyhow, up to you if you are okay to use rdrand without reservation. For many non-cryptographic purposes it will be fine.

I choose to trust open libraries that don't hide things, over implementations that have hidden secrets that can't be verified. Claims about security without proof are worthless. Intel;s claims about their super-uber-rdrand are also worthless. No serious cryptography expert accepts such claims without proof. Amateurs shouldn't dismiss the experts so easily IMO. Experts know what they are talking about more than everyone else, that's why they are the experts.
Post 30 May 2022, 18:32
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 575
Location: Ukraine
Overclick
Quote:

Experts know what they are talking about more than everyone else, that's why they are the experts.

You did not answered. Conspiracy theories doesn't make them experts.
Quote:

The bedrock of cryptography is having good random numbers.

What is problem to have it from rdrand?
What if someone break the algorithm they declared to use to take random numbers from rdrand? How blind cpu will react on that? Analyse full code? No way man, it is impossible at all.
As I said (1) and (2) have to work in one team for that bloody plan, prepare for exact OS and config. How much it cost? And as I said there is no need for (2). (1) can do all of the job. If you trust them to make the key, then what is matter how they rob you next?
CPU developed for years and soft can get changes everyday. How you believe they manage it?
(2) cannot work alone. For example: 'secret government' expect you get random bytes one by one but you did not. You skip some, shift or any else mixing operations == PLAN WASTED Very Happy
Post 30 May 2022, 19:54
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1884
Furs
revolution wrote:
The bedrock of cryptography is having good random numbers. So to say it isn't necessary is really bad. Without randomness cryptography isn't possible. All you end up with is encoding and transformations, and no security.

Anyhow, up to you if you are okay to use rdrand without reservation. For many non-cryptographic purposes it will be fine.

I choose to trust open libraries that don't hide things, over implementations that have hidden secrets that can't be verified. Claims about security without proof are worthless. Intel;s claims about their super-uber-rdrand are also worthless. No serious cryptography expert accepts such claims without proof. Amateurs shouldn't dismiss the experts so easily IMO. Experts know what they are talking about more than everyone else, that's why they are the experts.
If an open library you're using has completely open/known source of randomness, how is that more secure than rdrand's source? Even assuming the NSA knows everything about rdrand's source, everyone know everything about the library you're using, so...?

You think "mixing bits" is not secure but an open library doing just that is, because...?

Hardware-assisted seeds (with hardware sources) are always possibly more random than anything else you can do. But sure, just mix rdrand with something else, XOR it or whatever. Can't do harm since they're supposedly uncorrelated (if they're correlated, you have bigger issues, because your source is the same as rdrand).
Post 31 May 2022, 12:54
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18840
Location: In your JS exploiting you and your system
revolution
Random generators of bits don't appear in the source code. They are random, that's the point. Each time you run to code it works with different values from the generator.

If the RNG is some hardware component, or some external component (like network timing, keystroke timing, mouse movements, clock drift, etc.), then it is fine for the software source code to be open, the data don't come from the source code. The software only works with the data it is given. Unpredictable data in => secure outputs.

It's all a solved problem. Cryptographers actually only consider something secure if they can see all the inner workings and still can't predict the outputs. Or they treat it with suspicion if it is a secret and can't examine it.

Intel, what are you hiding? Show your implementation and prove it is genuine.
Post 31 May 2022, 13:01
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1462
Location: Toronto, Canada
AsmGuru62
I wonder if anyone at Intel is aware of this forum.
Very Happy
Post 31 May 2022, 14:46
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.