Show HN: Feistly – Cryptographically secure ID obfuscation with Feistel cipher(github.com)

2 pointsby jundev765 bulan yang lalu1 comments

Show HN: Feistly – Cryptographically secure ID obfuscation with Feistel cipher

https://github.com/JunDev76/feistly

I built Feistly to hide auto-increment IDs in URLs with tamper detection.

Most ID obfuscation libraries (Hashids, Sqids, Optimus) are reversible encodings. If you know the algorithm, you can decode tokens or manipulate them without the server detecting it. Feistly uses a Feistel cipher with HMAC-SHA256 to provide:

- Tamper detection: Modified tokens fail validation - Domain separation: User ID 100 and Order ID 100 generate different tokens with the same key - Format-preserving encryption: 64-bit input to 64-bit ciphertext, deterministic

The tradeoff is speed. Feistly does ~60K ops/sec vs millions for Hashids, but for most web apps database queries are the bottleneck anyway.

Example:

  const feistly = new Feistly({ masterKey: process.env.KEY });
  const token = feistly.encrypt("user", 12345); // "7nX4kP2mQ"
  feistly.decrypt("user", token); // "12345"

GitHub: https://github.com/jundev76/feistly npm: https://www.npmjs.com/package/feistly

Zero dependencies (Node.js crypto only), TypeScript native, includes benchmarks.

Feedback welcome – is this solving a real problem or is it overengineering?

1 comments

rishi_blockrand5 bulan yang lalu

Interesting choice using a Feistel cipher for format-preserving encryption here. It’s a solid step up from Hashids for preventing sequential ID discovery.

I’ve been looking into the 'Integrity Gap' in HMAC systems lately—specifically how to prove to an external auditor that the server secret (your masterKey) wasn't speculatively rotated or manipulated before a token was generated. In high-stakes environments like verifiable gaming or sensitive audit trails, the server holding the entropy is often a trust bottleneck.

Have you considered a model where the seed/key is anchored to a decentralized beacon like Drand? I've been experimenting with a 'Commit-Reveal' alternative where the final result is dependent on a future beacon round. It effectively removes the 'Last-Look' advantage from the server. Curious if you see a place for decentralized entropy in ID obfuscation for apps requiring a public audit trail