For those in a hurry, this is NOT related to the controversial Dual_EC_DRBG planted inside NIST's SP800-90A.
About the two RNGs:
The Microsoft BCRYPT layer based one is over their C API. BCryptGenRandom is following NIST SP800-90A's CTR_DRBG (i.e. uses an approved block cipher, AES, to create random bits). However it is unclear if it uses a hardware random source as seed (or part of the seed)...
The Microsoft .NET RNGCryptoServiceProvider is C# based. Looking at the .NET source code (or here), I see it end up calling the C++ method CapiNative.GenerateRandomBytes(). There should have been a P/Invoke stub for the C#=>C++ transition but I couldn't find it anywhere in the framework source. So I have no idea how it's actually implemented.
Does anyone have additional information on these two random number generators? Do either/both use HW random seeds (either via diode noise in older intels or the controversial RDRAND in the latest intels).
PS: Not sure it this should be at Security, StackOverflow or Cryptography ...
The Microsoft .NET RNGCryptoServiceProvider is a C# based
Not exactly, the managed framework class is just a thin wrapper over the Crypto api built into Windows. All the System.Security.Cryptography classes whose name end with ServiceProvider are wrappers for the native API. Those whose name ends in Managed are implemented in pure managed code. Accordingly, the XxxServiceProvider classes use FIPS validated cryptogaphy, and the XxxManaged classes are not.
It is not exactly pinvoke, it uses a common mechanism to make direct calls in CLR code. The jitter consults a table with addresses of C++ functions and compiles the CALL machine code instruction directly. The mechanism is described in this answer. Having a look at the actual code isn't possible, it isn't included in the SSCLI20 distribution and was altered to use the QCall mechanism in .NET 4.
So the assertion is unprovable, but it is pretty likely that RNGCryptoServiceProvider and the algorithm provider you pass to BCryptGenRandom() use the same source for random numbers. Which in Windows is an unnamed exported function in advapi.dll, this answer gives an excellent summary of what it uses.
If this truly concerns you and you want a reliable source of information then don't take advice from a free Q+A web site for your security needs. Call Microsoft Support.
Microsoft RNGCryptoServiceProvider is mentioned in RFC 4086:
7.1.3. Windows CryptGenRandom
Microsoft's recommendation to users of the widely deployed Windows
operating system is generally to use the CryptGenRandom pseudo-random
number generation call with the CryptAPI cryptographic service
provider. This takes a handle to a cryptographic service provider
library, a pointer to a buffer by which the caller can provide entropy
and into which the generated pseudo-randomness is returned, and an
indication of how many octets of randomness are desired.
The Windows CryptAPI cryptographic service provider stores a seed
state variable with every user. When CryptGenRandom is called, this is
combined with any randomness provided in the call and with various
system and user data such as the process ID, thread ID, system clock,
system time, system counter, memory status, free disk clusters, and
hashed user environment block. This data is all fed to SHA-1, and the
output is used to seed an RC4 key stream. That key stream is used to
produce the pseudo-random data requested and to update the user's seed
state variable.
Users of Windows ".NET" will probably find it easier to use the
RNGCryptoServiceProvider.GetBytes method interface.
Related
Note that this is not my application, it is an application I am pentesting for a client. I usually ask questions like this on https://security.stackexchange.com/, however as this is more programming related I have asked on here.
Granted, RFC 4122 for UUIDs does not specify that type 4 UUIDs have to be generated by a Cryptographically Secure Pseudo Random Number Generator (CSPRNG). It simply says
Set all the other bits to randomly (or pseudo-randomly) chosen
values.
Although, some implementations of the algorithm, such as this one in Java, do use a CSPRNG.
I was trying to dig into whether Microsoft's implementation does or not. Mainly around how .NET or MSSQL Server generates them.
Checking the .NET source we can see this code:
Marshal.ThrowExceptionForHR(Win32Native.CoCreateGuid(out guid), new IntPtr(-1));
return guid;
Checking the CoCreateGuid docco, it states
The CoCreateGuid function calls the RPC function UuidCreate
All I can find out about this function is here. I seem to have reached the end of the rabbit hole.
Now, does anyone have any information on how UuidCreate generates its UUIDs?
I've seen many related posts:
How Random is System.Guid.NewGuid()? (Take two)
Is using a GUID a valid way to generate a random string of characters and numbers?
How securely unguessable are GUIDs?
how are GUIDs generated in SQL Server?
The first of which says:
A GUID doesn't make guarantees about randomness, it makes guarantees
around uniqueness. If you want randomness, use Random to generate a
string.
I agree with this except in my case for random, unpredictable numbers you'd of course use a CSPRNG instead of Random (e.g. RNGCryptoServiceProvider).
And the latter states (actually quoted from Wikipedia):
Cryptanalysis of the WinAPI GUID generator shows that, since the
sequence of V4 GUIDs is pseudo-random; given full knowledge of the
internal state, it is possible to predict previous and subsequent
values
Now, on the other side of the fence this post from Will Dean says
The last time I looked into this (a few years ago, probably XP SP2), I
stepped right down into the OS code to see what was actually
happening, and it was generating a random number with the secure
random number generator.
Of course, even if it was currently using a CSPRNG this would be implementation specific and subject to change at any point (e.g. any update to Windows). Unlikely, but theoretically possible.
My point is that there's no canonical reference for this, the above was to demonstrate that I've done my research and none of the above posts reference anything authoritative.
The reason is that I'm trying to decide whether a system that uses GUIDs for authentication tokens needs to be changed. From a pure design perspective, the answer is a definite yes, however from a practical point of view, if the Windows UuidCreate function does infact use a CSPRNG, then there is no immediate risk to the system. Can anyone shed any light on this?
I'm looking for any answers with a reputable source to back it up.
Although I'm still just some guy on the Internet, I have just repeated the exercise of stepping into UuidCreate, in a 32-bit app running on a 64-bit version of Windows 10.
Here's a bit of stack from part way through the process:
> 0018f670 7419b886 bcryptPrimitives!SymCryptAesExpandKeyInternal+0x7f
> 0018f884 7419b803 bcryptPrimitives!SymCryptRngAesGenerateSmall+0x68
> 0018f89c 7419ac08 bcryptPrimitives!SymCryptRngAesGenerate+0x3b
> 0018f8fc 7419aaae bcryptPrimitives!AesRNGState_generate+0x132
> 0018f92c 748346f1 bcryptPrimitives!ProcessPrng+0x4e
> 0018f93c 748346a1 RPCRT4!GenerateRandomNumber+0x11
> 0018f950 00dd127a RPCRT4!UuidCreate+0x11
It's pretty clear that it's using an AES-based RNG to generate the numbers. GUIDs generated by calling other people's GUID generation functions are still not suitable for use as unguessable auth tokens though, because that's not the purpose of the GUID generation function - you're merely exploiting a side effect.
Your "Unlikely, but theoretically possible." about changes in implementation between OS versions is rather given the lie by this statement in the docs for "UuidCreate":
If you do not need this level of security, your application can use the UuidCreateSequential function, which behaves exactly as the UuidCreate function does on all other versions of the operating system.
i.e. it used to be more predictable, now it's less predictable.
I know to use the RNGCryptoServiceProvider, but is there anything special that I need to do to ensure that it's not using the same seed each time (such as at start-up)? Do I need to pull some data from outside sources on initialization? Or does the system do this for me?
Great Microsoft documentation, could not find anything about the algorithm or the seeding.
Wikipedia to the rescue:
Windows developers have several alternative means of accessing the CryptGenRandom functionality; these alternatives invoke the same algorithm and share the same security characteristics, but may have other advantages.
...
Using RNGCryptoServiceProvider
Programmers using .NET should use the RNGCryptoServiceProvider Class
Note that Wikipedia seems outdated, for more up to date information, check the Microsoft pages of the CryptGenRandom function
Note that this answer is only valid if you actually get the Microsoft CSP that uses the CryptGenRandom function. If you are on a non-Windows platform, or if you are refering to a different CSP, then check out those specific runtime configurations.
I've got a question regarding C#.
I am currently working on a medical software product, and one of the important things is to make sure that the patient's data is encrypted. I got two questions regarding this:
1.) How secure is the Microsoft .NET implementation of AES (Rijndael) from System.Security.Cryptography? Does it have any known security flaws, or am I fine just using the MS implementation? (note, I know the basic background of how these algorithms work, but I am not really that deep into it to get an idea of how it works).
2.) Since the data is stored on the same PC as the application, how hard is it to get information from a C# application? Assuming I have somewhere in the code
string encrypPassword = "ThisIsMyPassword";
string encryptedString = EncryptString(ClearString, encrypPassword);
// save encryptedString to harddrive
I know that an attacker could just go down to the assemble code, and at that point there is nothing at all I can do against this (the system has to be able to encrypt / decrypt the data), but is there like a shortcut for C# to get the encrypPassword, since it is managed, or does something like this still require you to go down to the assemble code?
If you have a fixed password compiled into your app, then you don't need to care about the security of AES and known security faults because your data is simply not secure. A sufficiently knowledgable person with access to the PC will be able to decrypt all the data.
And locating a fixed password usually doesn't require any programming knowledge. A good hex editor will do in most case. You don't even need to know what programming language was used.
If your data is used by a single user, then you can tie the password for the patient data to his or her Windows password (or account). Windows provides some specific functions for that. See http://msdn.microsoft.com/en-us/library/aa302402.aspx for how to access it from .NET.
In answer to the first part of your original question - the native Windows implementation of AES is NIST certified to be FIPS 140-2 compliant. Access to the certified implementation is limited to:
Using the Windows Crypto API
Using the CAPICOM com wrapper to the Windows Crypto API
Using the .Net AesCryptoServiceProvider class in the System.Security.Cryptography namespace (this class did not become available until .Net Framework 3.5)
That being said, the implementation in the RijndaelManaged class is the same, it just has not been thru the NIST certification process (this process is very long and very expensive).
The Aes algorithm is very secure (military grade encryption - especially the 256 bit key variant).
The biggest concern (agreeing with the posters above) is keeping your encryption password embedded in the application in plain text.
To store your password data you could use SecureString class from System.Security namespace.
Most decent obfuscators will encrypt the strings from your code before storing them in the assembly's strings section, and inject a method to decrypt them before use. These techniques have also long since been reverse engineered by disassemblers.
Realistically, there is almost no way to really safely store a string in any programming language. Someone can pretty much always either find the string, or reverse engineer your logic used to build it. The best thing you can do is stow down the attacker long enough to make it not worth their time and effort.
In your case, I would probably store the password encrypted in the app (as in, encrypt it yourself manually outside your app, and copy/paste it in). Possibly split it into parts so it isn't stored as a single string. Then put it back together and unencrypt it at runtime, then at runtime store it in a SecureString. Also invest in a good obfuscator, as it will help mask your unencryption logic (which will become the weak link in the security).
I am in need of a PGP service for .NET that will provide the following:
Encryption/decryption of files provided as byte arrays and/or streams (e.g. writing to hard drive and having the service read it is unacceptable)
Use of arbitrary keys passed in as byte arrays and/or streams
Needs to work for a headless service running on a server with nobody watching it (no modal popups or user input required)
We've felt out a couple of products but not been totally pleased with how any of them worked. Are there any suggestions? Thanks!
It's hard to guess what you could try as there are not much OpenPGP implementations for .NET. Namely, OpenPGPBlackbox package of our SecureBlackbox product is the only comprehensive self-contained implementation for .NET (BouncyCastle offers something as well, but they seem to be limited to older RFC 2440). You are welcome to check OpenPGPBlackbox and if you have problems with it, contact our technical support as described on product pages.
I'm looking at sending encrypted data between a Silverlight client and a native code (C++) server using WCF. I was looking at using the AesManaged class to encrypt data the client sends back to the server, but was wondering about the decryption. There is an assumption that if the AesManaged class is implemented against the AES specification it should be cross-compatible with any C++ AES library, but given experience with Microsoft's (and other vendors') "interpretations" of specifications previously I felt I should confirm it if possible.
I plan on building a prototype but I was hoping for an answer from someone who has experience in this area already. Using C++/CLI or C# for access to the AesManaged class isn't an option as I'm dealing with legacy code that I am adding functionality to.
All I can tell you is that it was good to ask; I cannot speak as to this specific interop, but I was trying to communicate with a piece of legacy software that used an older native implementation called AesLib, and I was trying to use AesCryptoServiceProvider. They wouldn't talk to each other, apparently because AesLib either uses a mode without an IV, or has a static or deterministic IV that I couldn't discover.
If you can get and reference the AES implementation that the native server is using, and implement an ICryptoServiceProvider-compatible wrapper around it, that would probably be the best guarantee that your message arrives intact (though this may cause its own problems). Otherwise, I would make sure I had all discoverable information about this implementation so I could configure AesManaged the same way. You'll need, at the very least, the key, IV, block size and mode.
I had successfully used C# AesManaged together with PHP's AES implementation long time ago (in Silverlight 2 Beta), so it is certainly possible.
However, you might want to study things like IV, paddings, block sizes and modes carefully to make sure settings for AES match.