doc: crypto docs updated to use good defaults for createDiffieHellman

Pull Request check-list

• Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with this change (including linting)?
• Is the commit message formatted according to CONTRIBUTING.md?
• If this change fixes a bug (or a performance problem), is a regression test (or a benchmark) included?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.

Affected core subsystem(s)

• Crypto API docs for createDiffieHellman

Description of change

Diffie-Hellman keys are composed of a generator a prime a secret_key and the public_key resulting from the math operation:

(generator ^ secret_key) mod prime = public_key

Diffie-Hellman keypairs will compute a matching shared secret if and only if the generator and prime match for both recipients. The generator is usually 2 and the prime is what is called a Safe Prime.

Usually this matching is accomplished by using standard published groups. We expose access those groups with the crypto.getDiffieHellman function.

createDiffieHellman is trickier to use. The original example had the user creating 11 bit keys, and creating random groups of generators and primes. 11 bit keys are very very small, can be cracked by a single person on a single sheet of paper. A byproduct of using such small keys were that it was a high likelihood that two calls of createDiffieHellman(11) would result in using the same 11 bit safe prime.

The original example code would fail when the safe primes generated at 11 bit lengths did not match for alice and bob.

If you want to use your own generated safe prime then the proper use of createDiffieHellman is to pass the prime and generator to the recipient's constructor, so that when they compute the shared secret their prime and generator match, which is fundamental to the algorithm.