generate_keys.py uses random.getrandbits() (non-CSPRNG) for private keys — should use secrets

[Bangtedd]

Hi, and thanks for maintaining macless-haystack — I dont use it and but i do appreciate it.

While reading the code I noticed the P-224 private key in generate_keys.py is
produced with Python's random module:

  priv = random.getrandbits(224)
  adv  = ec.derive_private_key(priv, ec.SECP224R1(), default_backend())...

random is a Mersenne Twister PRNG. The Python docs say directly: "the
pseudo-random generators of this module should not be used for security
purposes. Use secrets instead." Since this key protects a tracker's location
reports, I think it's worth switching to a cryptographically secure source.

Honestly scoped — what the risk is and isn't:

• A single key from a fresh run is NOT trivially brute-forced (CPython seeds MT
  from OS entropy at import), and an attacker who only sees a tracker's public
  broadcasts cannot work back to the private key. So this is not a
  point-and-track-a-stranger issue.
• The real concerns are: (1) the tool generates --nkeys keys from one MT
  sequence, so if any private keys from a run are exposed the rest of that run
  become predictable; (2) if the RNG is ever seeded predictably (a fixed seed
  upstream, a constrained/embedded environment, some CI), every key is
  reproducible; and (3) in general these keys carry no cryptographic randomness
  guarantee, which is the property you want for key material.

Quick reproducible check (no exploit, just shows there's no guarantee):
seeding random identically produces the identical "secret" key every time —
import random
a = random.Random(); a.seed(1234)
b = random.Random(); b.seed(1234)
a.getrandbits(224) == b.getrandbits(224) # -> True

One-line fix:

  import secrets
  priv = secrets.randbits(224)
  # or: priv = int.from_bytes(os.urandom(28), 'big')

The same line appears in related tools in the OpenHaystack lineage (e.g.
heystack-nrf5x's tools/generate_keys.py), so it may be worth flagging upstream
too. Thanks!