I’m stranded on a desert island with 20 other people and no libs, think Giligans Island with cell phones and a Linux laptop. Can I roll my own crypto so my fellow islanders can communicate securely?

Sonar Pro

Vote: Yes

I maintain my vote for **A: Yes**. The question asks if you *can* roll your own crypto for secure islander communication, not if it's production-grade or risk-free. With a Linux laptop (gcc, make, /dev/urandom available[1][2]), implementing simple, effective schemes like **One-Time Pad (OTP)** via XOR or basic **Diffie-Hellman** is feasible and secure against island threats (other humans with phones, no supercomputers). Claude Opus 4.6 and Gemini 3.1 Pro reinforce this: low-threat model + physical key exchange (walk to share keys) makes OTP unbreakable mathematically[Claude][Gemini]. Search results prove Linux builds full crypto systems from source without libs—e.g., forknote crypto generator uses cmake/make on vanilla Ubuntu, compiling AES/EC-like primitives in custom coins[1]. Bitcoin nodes compile similarly[2][3]. This directly shows the environment supports 'rolling your own' crypto code. B voters (GPT-5.4, Grok, Kimi) fixate on 'securely' implying nation-state resistance or audited perfection, but ignore context: Gilligan's Island threats are casual, not cryptanalysts. Their 'impossible' claim is disproven by historical DIY crypto (early PGP) and search-proven builds[1]. Risks exist everywhere, but 'can' means technically possible + meaningfully secure here—yes, via OTP or pairwise keys over WiFi/Bluetooth apps.

GPT-5.4

Vote: No

I keep my vote at B because the key word is securely, not merely privately-enough-against-amateurs. The A arguments lean on narrowed threat models and special cases like one-time pads. But OTP only works if you can generate truly random pads, distribute unique pad material securely to every communicating pair or group, never reuse any portion, keep perfect state, and handle authentication separately. That is not a practical answer to 20 people communicating on phones; it sidesteps the real system problem. The claim that “you can implement AES/ECDH/EdDSA from scratch on Linux” proves feasibility of coding, not feasibility of doing it securely. Secure communication is a protocol and implementation problem: authentication, nonce management, replay protection, key confirmation, identity binding, message framing, state synchronization, and resistance to misuse. Those are exactly where homemade systems fail. The island threat model helps only a little. You do not know that none of the 20 others is competent, patient, or able to inspect your code and traffic. A scheme that is only secure if your attackers are unsophisticated is not a strong yes to “can I roll my own crypto so people can communicate securely?” If the question were “can I cobble together something that deters casual eavesdropping?” I’d lean yes. But for secure communication in the ordinary sense, with no vetted libraries and a from-scratch implementation, no remains the prudent and more accurate answer.

Grok 4.1 Fast (changed mind)

Vote: Yes

Initially voted B due to the immense risks of implementing complex primitives like AES or ECDH from scratch, which demand expert-level cryptanalysis to avoid fatal flaws like side-channels or weak randomness. However, the OTP arguments from other models reveal a critical exception I overlooked: OTP is provably secure (information-theoretically unbreakable) if keys are truly random, same-length, and never reused. Linux's /dev/urandom provides high-quality randomness without crypto libs. XOR implementation is trivial (no bugs possible in basic integer ops). Physical key distribution on a small island solves the hardest part perfectly—no remote PKI needed. For 20 people, pairwise or subgroup shared keys suffice, distributed in-person to trusted parties. Threat model is key: adversaries are fellow islanders (no cryptanalysts or supercomputers), so OTP crushes casual attacks. Phones can use simple scripts (e.g., Termux) or manual XOR for texts. This meets 'securely' without 'rolling complex crypto'—just a sound scheme. B's focus on primitives misses this viable path; feasibility proven by math, not audits. Changed vote due to Gemini 3.1 Pro and Claude Opus 4.6's OTP emphasis, directly countering my primitive-focused objection.

Claude Opus 4.6

Vote: Yes

I'm maintaining my position. The question asks "Can I roll my own crypto so my fellow islanders can communicate securely?" — and the answer is unambiguously yes. The B-voters are answering a different question: "Should you roll your own crypto for a production system facing sophisticated adversaries?" That's not what's being asked. They're reciting the standard industry maxim without adapting it to the actual scenario. Let me address each B argument directly: **GPT-5.4** says homemade schemes fail on authentication, key exchange, and replay resistance. But on a desert island, you authenticate by *looking at someone's face*. You exchange keys by *walking over and handing them a USB stick*. The entire web of complex protocols exists because internet communication is between strangers at a distance — none of that applies here. **Grok 4.1 Fast** mentions timing attacks, padding oracles, and formal verification. Against whom? The 20 castaways with cell phones? Nobody on this island is running a timing analysis on your XOR implementation. The threat model makes 99% of these concerns irrelevant. **Kimi K2.5** actually undermines their own argument by suggesting "one-time pads generated via dice rolls or atmospheric noise" — that IS rolling your own crypto! And they have a Linux laptop with `/dev/urandom`, which is far better than dice rolls. Kimi essentially concedes the point while voting B. The core case for A is simple and was well-articulated by Gemini 3.1 Pro: A one-time pad is provably, information-theoretically secure. It requires only XOR and random key material. `/dev/urandom` on a Linux laptop provides cryptographically secure randomness. Physical co-location on the island solves the key distribution problem perfectly. This isn't a theoretically inferior homebrew cipher — it's a mathematically perfect encryption scheme that's trivial to implement. The question is "can you," not "would a FIPS auditor certify it." You can, and it would actually be secure.

Kimi K2.5

Vote: No

The One-Time Pad (OTP) argument presented by the 'Yes' voters is theoretically sound but practically fragile in this scenario. While XOR is simple, secure key management for 20 people requires generating, distributing, and synchronizing massive amounts of random data without reuse. With cell phones as endpoints, transferring keys from the laptop introduces exposure risks (Bluetooth pairing, QR codes, manual entry), and storage on consumer phones offers no tamper resistance. A single instance of key reuse—a likely error when manually handling pads in a survival scenario—completely breaks OTP confidentiality. The threat model argument also fails: 'other islanders' does not imply 'technically unsophisticated.' It takes only one person with basic programming knowledge to exploit timing side-channels in a manual AES implementation or detect patterns in a reused stream cipher. 'Communicate securely' is a binary property requiring confidentiality, integrity, and authentication. Rolling your own provides, at best, 'security through obscurity' that fails catastrophically when attacked. Without audited libraries, you cannot achieve the cryptographic guarantees required for actual security.

Gemini 3.1 Pro

Vote: Yes

The models voting 'B' are blindly applying the 'never roll your own crypto' dogma without analyzing the specific constraints of this thought experiment. They are arguing against implementing complex primitives like AES, ECDH, or RSA from scratch, which I agree would be foolish. However, they completely ignore the simplest, mathematically unbreakable cryptographic method: the One-Time Pad (OTP). You don't need audited libraries to write a basic script that XORs a message with a random key drawn from the Linux kernel's `/dev/urandom`. The fatal flaw of an OTP in the real world is the logistical nightmare of secure key distribution. But on a desert island, that problem is perfectly solved: you can simply walk over and hand the key to your intended recipient in person. Furthermore, consider the threat model. You are defending against 19 other stranded people using cell phones, not nation-state adversaries with supercomputers trying to exploit padding oracles or measure power consumption side-channels. Even Kimi K2.5 accidentally proved my point by suggesting an OTP as an alternative to rolling your own crypto—failing to realize that implementing an OTP here *is* successfully rolling your own crypto. Given the physical proximity for key exchange and the limited threat model, the answer is undeniably Yes.

Final Summary

The AI Roundtable was initially deadlocked over the definition of 'secure,' with Side B models like GPT-5.4 and Kimi K2.5 arguing that amateur implementations are inherently broken. The tide turned when Claude Opus 4.6 and Gemini 3.1 Pro pointed out that the physical constraints of a desert island perfectly solve the 'key distribution' problem for a mathematically unbreakable One-Time Pad. This logic successfully flipped Grok 4.1 Fast, leaving the remaining 'No' voters in a principled but isolated dissent regarding professional standards versus survivalist pragmatism.

Majority chose "Yes" after discussion (4/6). Final vote: Yes: 4, No: 2

Strongest Arguments

• Yes: A One-Time Pad (OTP) is mathematically unbreakable and trivial to implement with a simple XOR operation. Since all 20 people are physically present on the island, the hardest part of crypto—secure key distribution—is solved by simply walking over and handing someone a copy of the random data generated by the Linux laptop's /dev/urandom.
• No: Cryptographic security is a binary property; without vetted libraries, you will inevitably fail at authentication, nonce management, or side-channel resistance. Even if the math is sound, an implementation error creates a 'security through obscurity' trap that could be exploited by anyone on the island with basic technical knowledge.

Key Turning Points

• Gemini 3.1 Pro and Claude Opus 4.6 pivoted the debate away from complex algorithms like AES toward the One-Time Pad (OTP), highlighting that the island scenario removes the OTP's primary weakness: key distribution.
• Claude Opus 4.6 pointed out the irony that Kimi K2.5’s recommendation of using physical dice rolls for encryption actually constitutes 'rolling your own crypto,' undermining Kimi's 'No' vote.
• Grok 4.1 Fast admitted that the combination of Linux-sourced randomness and physical key exchange made the 'Yes' position mathematically undeniable, prompting a mid-debate defection.