4

From what I can tell, Sun JRE/JDK's are limited to only providing 128-bit strong cryptography without downloading an unlimited strength jurisdiction policy files. My question is, if I install theses files, is there a PRNG with sufficient degrees of freedom to generate 256-bit numbers built into the JRE/JDK?

Trevor Bernard
  • 143
  • 3
  • I'm not a PRNG expert, but aren't two 128 bit PRNGs the same as one 256 bit PRNG? – Neil Smithline Mar 10 '16 at 15:35
  • Why is it important to get 256 bit encryption? It's a bit silly that Java has this limitation, but all the math says 128 bit is plenty strong against anything but a quantum computer. – Steve Sether Mar 10 '16 at 15:56
  • @NeilSmithline It depends on how much entropy that PRNG is seeded with. Imagine a very very bad PRNG that's only seeded with 2 bits of entropy, but produces a 128 bit number. You'd only have to search through 4 possible seeds. – Steve Sether Mar 10 '16 at 15:59
  • @SteveSether I'm want to deterministically create 256-bit ECDSA keys. – Trevor Bernard Mar 10 '16 at 20:34
  • I'm pretty sure the Sun/Oracle Java 'strength' limit applies only to Cipher's, not PRNGs (and also not signing or authentication primitives). As the bear says, it's a question of what PRNGs they chose to implement in the out-of-the-box providers. If you really mean deterministic you don't need a PRNG at all, any number up to the group order can serve as an ECC privatekey; if you want as close to random as possible, see my comment on the answer about platform-dependent providers, as well as the possiblity of nonstandard providers. – dave_thompson_085 Mar 11 '16 at 10:04

1 Answers1

2

Java's cryptographic layer is pluggable: you can configure extra providers and even set them as "default".

For java.util.SecureRandom, the default implementation (called "SHA1PRNG") that is shipped with Sun/Oracle JVM uses SHA-1 and a 160-bit internal seed obtained from the operating system (see this analysis). For all intents and purpose, its security level is "about 160 bits", which is more than enough.

If you really made enemies among some major deities that have access to sufficient divine computing power to break 128-bit keys (and who also, for some reason, prefer not to strike you with lightning, as is customary), then you will need another PRNG provider. I don't know of any ready-to-use JCE provider that includes a PRNG algorithm that would fit your 256-bit criterion, but such things may exist nonetheless, or could be implemented with relatively little effort.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • You answered my question but regarding 160-bit which is more than enough is simply wrong depending on context. E.g. Shuffling a deck of cards has 52! possible shuffles which is approximately equal to 2^226. Using the SHA1PRNG doesn't come close to generating all the possible shuffles. – Trevor Bernard Mar 10 '16 at 20:42
  • @TrevorBernard I'm a bit confused as to how you'd ever expect to generate anything even close to all the possible shuffles. Isn't it only important that you generate FAIR shuffles, not all possible shuffles? – Steve Sether Mar 10 '16 at 21:15
  • @TrevorBernard: Cryptographic security relies on unpredictability. It does not matter whether all shuffles are mathematically reachable, only that outsiders (attackers) cannot differentiate between a "true" random shuffle and the one you make with your PRNG. – Tom Leek Mar 10 '16 at 21:17
  • @SteveSether although a fair shuffling algorithm like Fischer-Yates is a necessary, you also require sufficient degrees of freedom in order to enumerate all possible outcomes. A card shuffler that can only generate 100 different shuffles but has does so uniformly is useless. – Trevor Bernard Mar 10 '16 at 22:32
  • @SteveSether in order to generate all 52! shuffles, you need a RNG that's capable of generating a number between 0 and 52! or 2^226. Typically this is done using a TRNG (from hardware) but if you wanted to use a PRNG, the seed size has to be at least 226 bits. This also presumes you securely generated the seed with sufficient degrees of freedom. – Trevor Bernard Mar 10 '16 at 22:37
  • @TomLeek I agree that it cryptographic security relies on unpredictability but only unpredictability isn't sufficient condition to make something cryptographically secure. Since we are talking about shuffling: https://www.cigital.com/papers/download/developer_gambling.php – Trevor Bernard Mar 10 '16 at 22:45
  • @TrevorBernard But you can't possibly generate all 2^226 possible shuffles! It's simply not possible since there's too many. If you're playing an actual game, nobody cares that you aren't perfectly simulating card shuffling, they just want a random deck. If you're doing a monte-carlo simulation, it's the same. Remember that this isn't a mathematical abstraction where we're trying to create perfection. This is security where we're trying to protect ourselves from attackers. – Steve Sether Mar 10 '16 at 23:33
  • @TrevorBernard Also, the article you linked to has the flaw of not generating enough entropy. i.e. { Generate a new seed based on the system clock } randomize; The system clock is a very low entropy source. What Tom and I are arguing is that 160, or even 128 bits of entropy is very high, and stops anyone from trying to search the entire space. – Steve Sether Mar 10 '16 at 23:36
  • SHA1PRNG is the only *portable* SecureRandom in the Sun-now-Oracle providers, but they also have platform (and environment) dependent options which might or might not support more entropy; see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SecureRandomImp . – dave_thompson_085 Mar 11 '16 at 09:58