I'm personally hostile to analogies and "dumbing down", because it can have the unintended effect that people take the analogy too far, or get stuck with the dumbed down version.
Your goal is to show the complexity, but without overwhelming the audience. You can do that by providing multiple layers.
In the main part of the text, speak mostly about consequences, leave out technical details: Encryption ensures the confidentiality of documents because knowledge of a key is needed to decrypt and thus read the document. This layer is written for the non-technical audience and should require no technical knowledge to understand. You would explain, say, the difference between encryption, hashing and cryptographic signatures, but not how they work.
Then you provide an option for the reader to study the topic more in detail, e.g.: see Appendix B for recommended encryption schemes.
Then in the appendix, you can dig into more technical details, e.g. which encryption algorithms and keylengths are recommended. This layer is written for a technical person or a person with basic technical knowledge, someone who can stomach technical terminology and a little bit of math. You would explain the different algorithms and their application, how to correctly use them and technical details of methods, but not explain the algorithms themselves.
Again, for the very low detail, like how ECB differs from CBC or why the CV is important except in those modes which use a nonce... you refer to footnotes or endnotes or another way to hide the third layer out of the way of the immediate text flow.
And if you want, you can add a fourth layer where you actually explain how AES or DH, etc. work. Though that layer has already been written by others and you could just refer to it.
You can apply the same principle to implementation details - the top layer speaks to the user, describing what the software does. The second layer speaks to the system administrator describing how to install and maintain it. The third layer speaks to the developer and describes the source code, how to modify it, etc.
The basic idea is to provide the details, but move them out of the way so that a reader not interested in them (or afraid that he'll not understand) can skip over them easily. The best way to accomplish that is to not have them in the main text. Appendices, footnotes, etc. were all invented for this purpose. You can also add a "technical part" at the end with individual chapters and refer to those. All you need is some references (back and forth!) so the reader who does want to dive into the details can quickly find his way back to the main text.