A software development company needs to share information between two remote servers, using encryption to protect it. A programmer suggests developing a new encryption protocol, arguing that using an

While the security of underlying cryptographic libraries does matter, this choice incorrectly implies the protocol's security ceiling is solely determined by the primitives, ignoring that protocol-level design flaws can independently break security regardless of strong algorithms.

Even when built with secure, well-vetted cryptographic algorithm libraries, new protocol designs introduce attack surfaces through flaws in how those primitives are composed, sequenced, or implemented - areas like improper nonce reuse, padding oracle vulnerabilities, or authentication gaps. This principle is captured in the well-known security maxim 'don't roll your own crypto,' which applies to protocols as much as algorithms. Established protocols like TLS have undergone years of public cryptanalysis, peer review, and real-world hardening that a newly developed protocol cannot replicate.

Although specialized training is relevant and desirable, this response focuses on the developer's credentials rather than the fundamental technical risk of introducing unknown protocol vulnerabilities, making it a weaker and less precise answer.

This choice is incorrect because security through obscurity is widely considered insufficient and unreliable; unproven protocols do not gain meaningful protection simply from being unknown, and this framing dangerously misrepresents the risk-benefit tradeoff.