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
Copy file name to clipboardExpand all lines: README.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -198,24 +198,24 @@ We'll start with using 32 characters. What 32 characters, you ask? Well, the [Ch
198
198
199
199
We're using the same __bits__ calculation since we haven't changed the number of IDs or the accepted risk of probabilistic uniqueness. But this time we use 32 characters and our resulting ID only requires 10 characters (and can carry 50 bits of entropy).
200
200
201
-
Now let's suppose we need to ensure the names of a handful of items are unique. Let's say 30 items. And let's decide we can live with a 1 in 100,000 probability of collision (we're just futzing with some code ideas). Using hex characters:
201
+
Now let's suppose we need to ensure the names of a handful of items are unique. Let's say 30 items. And let's decide we can live with a 1 in 100,000 probability of collision (we're just futzing with some coding ideas). Using hex characters:
Okay, we probably wouldn't use 4 characters (and what's up with those characters?), but you get the idea.
218
+
Okay, we probably wouldn't use 4 characters (and what's up with those characters?), but you get the idea. The [Efficiency](#Efficiency) explains the 3rd argument of `false`.
219
219
220
220
Suppose we have a more extreme need. We want less than a 1 in a trillion chance that 10 billion base 32 strings repeat. Let's see, our risk (trillion) is 10 to the 12th and our total (10 billion) is 10 to the 10th, so:
221
221
@@ -363,7 +363,7 @@ Compare that to the `entropy-string` scheme. For the example above, slicing off
363
363
364
364
But there is an even bigger issue with the above code from a security perspective. `Math.random`*is not a crytographically strong random number generator*. **_Do not_** use `Math.random` to create secure IDs! This highlights an important point. Strings are only capable of carrying information (entropy); it's the random bytes that actually provide the entropy itself. `entropy-string` automatically generates the necessary number of bytes needed to create a random string using the `crypto` library.
365
365
366
-
However, if you don't need cryptographically strong random strings, you can request `entropy-string` use `Math.random` rather than the `crypto` library to generate randomness:
366
+
However, if you don't need cryptographically strong random strings, you can request `entropy-string` use `Math.random` rather than the `crypto` library by passing in a 3rd argument of `false`:
367
367
368
368
```js
369
369
constentropy=require('entropy-string')
@@ -372,32 +372,32 @@ However, if you don't need cryptographically strong random strings, you can requ
372
372
373
373
> PQ9dmqJ7g6
374
374
375
-
When using `Math.random`, the `entropy-string` scheme uses 48 of the 52(ish) bits of randomness from each call to `Math.random`. That's more efficient than the above code snippet but less so than using `crypto` bytes.
375
+
When using `Math.random`, the `entropy-string` scheme uses 48 of the 52(ish) bits of randomness from each call to `Math.random`. That's more efficient than the above code snippet but less so than using bytes from `crypto`.
376
376
377
377
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.
378
378
379
379
[TOC](#TOC)
380
380
381
381
## <aname="CustomBytes"></a>Custom Bytes
382
382
383
-
As described in [Efficiency](#Efficiency), `entropy-string` automatically generates random bytes using the `crypto` library. But you may have a need to provide your own bytes, say for deterministic testing or to use a specialized byte genterator. The `entropy.randomStringWithBytes` function allows passing in your own bytes to create a string.
383
+
As described in [Efficiency](#Efficiency), `entropy-string` automatically generates random bytes using the `crypto` library. But you may have a need to provide your own bytes, say for deterministic testing or to use a specialized byte generator. The `entropy.randomString` function allows passing in your own bytes to create a string.
384
384
385
385
Suppose we want a string capable of 30 bits of entropy using 32 characters. We pass in 4 bytes (to cover the 30 bits):
386
386
387
387
```js
388
388
constentropy=require('entropy-string')
389
389
390
-
let bytes:RandomString.Bytes= [250, 200, 150, 100]
391
-
let string =entropy.randomStringWithBytes(30, entropy.charSet32, bytes)
390
+
let bytes:RandomString.Bytes=newUint8Array[250, 200, 150, 100]
391
+
let string =entropy.randomString(30, entropy.charSet32, bytes)
392
392
```
393
393
394
394
> string: Th7fjL
395
395
396
-
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.randomStringWithBytes` throws an `Error` if the string cannot be formed from the passed bytes.
396
+
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.randomString` throws an `Error` if the string cannot be formed from the passed bytes.
0 commit comments