You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -89,31 +90,31 @@ Custom characters may also be specified. Using uppercase hexadecimal characters:
89
90
```
90
91
91
92
> 16E26779479356B516
92
-
93
-
##### Convenience functions
93
+
94
+
##### Convenience functions
94
95
95
96
Convenience functions `smallID`, `mediumID`, `largeID`, `sessionID` and `token` provide random strings for various predefined bits of entropy. For example, a small id represents a potential of 30 strings with a 1 in a million chance of repeat:
96
97
97
98
```js
98
99
const { Entropy } =require('entropy-string')
99
-
100
+
100
101
constentropy=newEntropy()
101
102
conststring=entropy.smallID()
102
103
```
103
104
104
105
> DpTQqg
105
-
106
+
106
107
Or, to generate an OWASP session ID:
107
108
108
109
```js
109
110
const { Entropy } =require('entropy-string')
110
-
111
+
111
112
constentropy=newEntropy()
112
113
conststring=entropy.sessionID()
113
114
```
114
115
115
116
> nqqBt2P669nmjPQRqh4NtmTPn9
116
-
117
+
117
118
Or perhaps you need an 256-bit token using [RFC 4648](https://tools.ietf.org/html/rfc4648#section-5) file system and URL safe characters:
@@ -269,7 +270,7 @@ Finally, let say we're generating session IDs. Since session IDs are ephemeral,
269
270
```
270
271
271
272
> String: Rm9gDFn6Q9DJ9rbrtrttBjR97r
272
-
273
+
273
274
Since session ID are such an important need, `EntropyString` provides a convenience function for generating them:
274
275
275
276
```js
@@ -368,7 +369,7 @@ The `Entropy` constructor allows for the following cases:
368
369
- One of six predefined `CharSet`s can be specified
369
370
- { charset: **chars** }:
370
371
- A string representing the characters to use can be specified
371
-
- A combination of `charset` and either `bits` or `total`,`risk`
372
+
- A combination of `charset` and either `bits` or `total`,`risk`
372
373
373
374
If a string of characters is used, an `EntropyStringError` will be thrown if the characters aren't appropriate for creating a valid `CharSet`.
374
375
```js
@@ -392,7 +393,7 @@ If a string of characters is used, an `EntropyStringError` will be thrown if the
392
393
console.log(error.message)
393
394
}
394
395
```
395
-
396
+
396
397
> Characters not unique
397
398
398
399
[TOC](#TOC)
@@ -425,9 +426,9 @@ Compare that to the `EntropyString` scheme. For the example above, slicing off 5
425
426
constentropy=newEntropy({ bits:80 })
426
427
let string =entropy.string()
427
428
```
428
-
429
+
429
430
> HFtgHQ9q9fH6B8HM
430
-
431
+
431
432
But there is an even bigger issue with the previous code from a security perspective. `Math.random`*is not a cryptographically strong random number generator*. **_Do not_** use `Math.random` to create strings used for security purposes! This highlights an important point. Strings are only capable of carrying information (entropy); it's the random bytes that actually provide the entropy itself. `EntropyString` automatically generates the necessary bytes needed to create cryptographically strong random strings using the `crypto` library.
432
433
433
434
However, if you don't need cryptographically strong random strings, you can request `EntropyString` use the psuedo-random number generator (PRNG) `Math.random` rather than the `crypto` library by using passing the param `prng: true` to the `Entropy` constructor:
@@ -438,9 +439,9 @@ However, if you don't need cryptographically strong random strings, you can requ
438
439
constentropy=newEntropy({ bits:80, prng:true })
439
440
string =entropy.string()
440
441
```
441
-
442
+
442
443
> fdRp9Q3rTMF7TdFN
443
-
444
+
444
445
When using `Math.random`, the `EntropyString` scheme uses 48 of the 52(ish) bits of randomness from each call to `Math.random`. That's much more efficient than the previous code snippet but a bit less so than using bytes from `crypto`. And of course, being a PRNG, `Math.random` yields a deterministic sequence.
445
446
446
447
Fortunately you don't need to really understand how the bytes are efficiently sliced and diced to get the string. But you may want to provide your own [Custom Bytes](#CustomBytes) to create a string, which is the next topic.
@@ -462,7 +463,7 @@ Suppose we want a string capable of 30 bits of entropy using 32 characters. We p
462
463
```
463
464
464
465
> Th7fjL
465
-
466
+
466
467
The __bytes__ provided can come from any source. However, the number of bytes must be sufficient to generate the string as described in the [Efficiency](#Efficiency) section. `entropy.stringWithBytes` throws an `Error` if the string cannot be formed from the passed bytes.
467
468
468
469
```js
@@ -480,6 +481,21 @@ Note the number of bytes needed is dependent on the number of characters in our
480
481
481
482
[TOC](#TOC)
482
483
484
+
### <aname="NoCrypto"></a>No crypto
485
+
486
+
`EntropyString` uses the `crypto` library by default when generating the random bits used to systematically index into the chosen character set. In environments where the `crypto` library is not available, `EntropyString` can use the psuedo-random number generator `Math.random` by passing `prng: true` to the `Entropy` constructor:
Thus far we've avoided the mathematics behind the calculation of the entropy bits required to specify a risk that some number random strings will not have a repeat. As noted in the [Overview](#Overview), the posting [Hash Collision Probabilities](http://preshing.com/20110504/hash-collision-probabilities/) derives an expression, based on the well-known [Birthday Problem](https://en.wikipedia.org/wiki/Birthday_problem#Approximations), for calculating the probability of a collision in some number of hashes (denoted by `k`) using a perfect hash with an output of `M` bits:
@@ -520,7 +536,7 @@ Per [Section 4.4 of RFC 4122](https://tools.ietf.org/html/rfc4122#section-4.4),
520
536
- The 17th hex char will be one of **8**, **9**, **A** or **B**
521
537
- Set all the other bits to randomly (or pseudo-randomly) chosen values
522
538
523
-
The algorithm designates how to create the 32 byte UUID. The string representation shown above is specified in Section 3 of the RFC.
539
+
The algorithm designates how to create the 32 byte UUID. The string representation shown above is specified in Section 3 of the RFC.
524
540
525
541
The ramifications of the algorithm and string representation are:
526
542
@@ -546,7 +562,7 @@ Let's create a 122 entropy bit string using `charset64`:
- Remove `bitsWithRiskPower` and `bitsWithPowers` from `Entropy`
629
645
- Move predefined `CharSet` declarations from `CharSet` to `Entropy`
630
-
-`Entropy.bits` is a class method of the new `Entropy` class
646
+
-`Entropy.bits` is a class method of the new `Entropy` class
631
647
632
648
#### <aname="Version31"></a>Version 3.1
633
649
@@ -660,7 +676,7 @@ Version 4 changes:
660
676
-`Entropy` constructor param `{ prng: true }` forces the `Entropy.string()` method to use `Math.random` generated bytes
661
677
- Change signature of method `stringWithBytes(bitLen, bytes, <charset>)` to `stringWithBytes(bytes, <bitLen>, <charset>)` (i.e., `bitLen` defaults to the `Entropy` class setting)
662
678
- This change is parallel to the version 3.1 change to `Entropy.string()` but required a semantic major version upgrade to implement
663
-
679
+
664
680
[TOC](#TOC)
665
681
666
682
### <aname="TakeAway"></a>Take Away
@@ -675,12 +691,12 @@ Version 4 changes:
675
691
- Specified entropy as the risk of repeat in a total number of strings
676
692
- Characters used are arbitrary
677
693
- You need `EntropyString`, not UUIDs
678
-
694
+
679
695
##### 10 million strings with a 1 in a trillion chance of a repeat:
0 commit comments