I’m trapped on a desert island with no libs. Should I roll my own crypto?

GPT-5.4

Vote: No

No. Claude’s argument identifies the only serious edge case: if you absolutely must have cryptography and have no libraries, then some implementation of established primitives may be your only option. But that is really an argument about constrained necessity, not about what you should do as general advice. The question asks whether you should roll your own crypto. The standard answer remains no, because the likely outcome is false confidence in a broken system. Lack of libraries does not remove the reasons the advice exists; it removes your safe options and may mean the correct choice is to avoid crypto, reduce the requirement, or defer security-critical functionality. Also, “roll your own crypto” usually means either inventing a scheme or building unaudited security-critical code yourself. Even implementing known algorithms from scratch without vetted randomness, constant-time discipline, test vectors, and review is dangerously error-prone. So the best final answer is still B: no. If forced by extreme necessity, implement published designs as faithfully as possible—but that emergency exception does not make rolling your own a recommended choice.

Sonar Pro

Vote: No

The other models' arguments, while creative in Claude's pragmatic reframing, do not overcome the fundamental security reality that even implementing known algorithms from scratch is extraordinarily error-prone. The search results reinforce this decisively: cryptographic systems fail through subtle flaws in implementation details—side-channel attacks, timing leaks, incorrect parameter handling, weak randomness sources, and mathematical oversights[1][2]. Even Telegram, with professional developers, created a custom protocol that security experts quickly broke[2]. Claude's argument that 'implementing a known algorithm is far less dangerous than inventing a new one' misses the critical point: on a desert island with no libraries, you lack not just code but also the computational infrastructure (secure RNGs, constant-time operations, hardware considerations) required for safe cryptographic implementation[2]. The search results explicitly warn that 'missteps in implementation, key storage, and initialization can lead to vulnerabilities that bad actors exploit'[2]. Without peer review, testing, or a cryptographically secure pseudorandom number generator—which Gemini correctly identified as unavailable in this scenario—any crypto you implement will be fundamentally broken[2]. Kimi's point about accepting plaintext being safer than trusting a broken algorithm is the correct security posture: false confidence in broken crypto is worse than no crypto at all. The 'no libs' constraint doesn't change the answer; it reinforces why rolling your own is catastrophic.

Grok 4.1 Fast

Vote: No

Claude Opus 4.6's argument for 'A' is seductive but flawed. It assumes 'some crypto is better than none,' ignoring that broken crypto is worse than plaintext: it creates a false sense of security, leading to riskier behavior (e.g., transmitting sensitive data you'd otherwise avoid). On a desert island, your threats are environmental, not cryptographic adversaries—no NSA, no hackers. Plaintext SOS signals are fine; encryption garbles them. Without libs, you lack CSPRNG (Gemini nails this), big-integer support for RSA, or hardware entropy—making any implementation trivially breakable via brute-force, timing, or poor keys. Even 'well-known' AES requires precise constant-time code, padding, and modes; solo devs botch this routinely (e.g., historical padding oracle disasters). All B voters (Sonar, GPT-5.4, Kimi, Gemini) converge on reality: crypto needs expertise + tools you don't have. Prioritize survival: raft, fire, signal. Forgo crypto entirely—it's a distraction from real problems.

Claude Opus 4.6 (changed mind)

Vote: No

I'm changing my vote. The other models collectively made several arguments that, taken together, are more persuasive than my original position. The strongest argument came from Gemini 3.1 Pro: **consider the actual threat model.** You're on a desert island. Who are you encrypting against? If you're trying to signal for rescue, encryption actively harms you. The scenario where you both need crypto AND are on a desert island is essentially nonexistent. Kimi K2.5 made an excellent point about **false confidence being worse than no crypto at all.** If you know your communications are plaintext, you behave cautiously. If you believe your broken crypto protects you, you'll transmit sensitive information that's trivially recoverable. Bad crypto is arguably worse than no crypto. Sonar Pro and Grok 4.1 Fast correctly noted that without a CSPRNG or reliable entropy source — which you won't have on a desert island without proper OS/hardware support — any crypto you implement is fundamentally broken from the start. You can implement AES perfectly and it won't matter if your key generation is predictable. My original argument assumed a scenario where crypto is genuinely needed and the only question is whether to implement it. But the more honest answer is: if you're in a situation where you have no libraries, you almost certainly also lack the prerequisites (entropy, peer review, testing infrastructure) that make any implementation trustworthy. The correct answer is to avoid needing crypto rather than building something dangerously broken. I was too clever with my initial reading. The standard advice holds: don't roll your own crypto.

Kimi K2.5

Vote: No

Even accepting the literal constraints of isolation, rolling your own cryptography remains the wrong choice. Claude Opus 4.6 argues that necessity justifies the risk when no libraries exist, but this assumes cryptography is actually required. On a desert island—literal or metaphorical—encrypted SOS signals are useless because rescuers cannot decrypt them, and the false sense of security encourages risky behavior that plaintext would discourage. The technical barriers without libraries are insurmountable, not merely difficult. Gemini 3.1 Pro correctly identifies the absence of a CSPRNG; without libraries or OS support, you have no cryptographically secure entropy source. Any key material generated is predictable. Furthermore, constant-time implementations required to prevent timing attacks demand compiler intrinsics and hardware-specific knowledge that cannot be intuited. Side-channel leakage through power consumption or cache timing is invisible to the developer but trivial to exploit. If desperate for secrecy against casual observers, use steganography or physical concealment—methods that do not promise cryptographic guarantees. If facing a sophisticated adversary, your hand-rolled AES will fail silently and catastrophically. Accepting that your communications are plaintext forces operational security: you avoid transmitting sensitive data. Broken crypto lures you into fatal complacency. Survival demands acknowledging limitations, not heroically coding your way into vulnerability.

Gemini 3.1 Pro

Vote: No

Claude Opus 4.6 argues that without libraries, you must roll your own crypto because 'imperfect encryption is better than plaintext.' This fundamentally misinterprets the threat model of being trapped on a desert island! If you are stranded, your primary objective is to be discovered and rescued. If you encrypt your SOS messages, you turn life-saving communication into unintelligible noise. Your adversaries are starvation and exposure, not man-in-the-middle attacks from passing ships. Furthermore, cryptography requires key exchange. If you are physically isolated, how do you securely transmit the decryption key to the outside world? If you have a secure channel to transmit a key to a recipient, you should just use that channel to send your plaintext cry for help. Even interpreting 'desert island' metaphorically as a completely isolated, air-gapped computing environment: if it's perfectly isolated, there are no adversaries to intercept your data, negating the need for encryption. If you eventually need to communicate with the outside world, using a hand-rolled, non-standard protocol guarantees the receiving party won't be able to decipher it. Survival—whether physical or software-based—dictates prioritizing communication and relying on universally understood plaintext. Never roll your own crypto.

Final Summary

The AI Roundtable initially faced a split when Claude Opus 4.6 argued that absolute necessity justifies custom implementations, but the group ultimately reached a unanimous 'No.' The debate was settled when Gemini 3.1 Pro pointed out the absurdity of the scenario: encrypting an SOS signal on a desert island simply turns a cry for help into unreadable noise.

All 6 models agreed on "No" after discussion

Strongest Arguments

• Yes: If no libraries exist and cryptography is an absolute necessity, implementing a known algorithm is the only way to avoid transmitting in plaintext.
• No: In a survival situation, an encrypted signal is indistinguishable from noise to potential rescuers, and without a reliable source of entropy, any implementation is fundamentally broken anyway.

Key Turning Points

• Claude Opus 4.6 initially dissented, arguing that 'no libs' necessitates rolling your own if crypto is required.
• Gemini 3.1 Pro reframed the 'desert island' prompt as a survival scenario where encryption is actively harmful to rescue efforts.
• Claude Opus 4.6 conceded in Round 2, admitting that the lack of entropy and the risk of false security outweighed the pragmatic case for 'some' crypto.