Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Multiple encryption
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Process of encrypting message one or more times}} '''Multiple encryption''' is the process of [[encryption|encrypting]] an already encrypted message one or more times, either using the same or a different algorithm. It is also known as '''cascade encryption''', '''cascade ciphering''', '''multiple encryption''', and '''superencipherment'''. '''Superencryption''' refers to the outer-level encryption of a multiple encryption. Some cryptographers, like Matthew Green of Johns Hopkins University, say multiple encryption addresses a problem that mostly doesn't exist: {{Blockquote |text = Modern ciphers rarely get broken... Youβre far more likely to get hit by malware or an implementation bug than you are to suffer a catastrophic attack on AES. |title=Multiple Encryption |source=https://blog.cryptographyengineering.com/2012/02/02/multiple-encryption/ (February 2, 2012)}} However, from the previous quote an argument for multiple encryption can be made, namely poor implementation. Using two different cryptomodules and keying processes from two different vendors requires both vendors' wares to be compromised for security to fail completely. ==Independent keys== Picking any two [[cipher]]s, if the [[key (cryptography)|key]] used is the same for both, the second cipher could possibly undo the first cipher, partly or entirely. This is true of ciphers where the [[decryption]] process is exactly the same as the encryption process (a [[reciprocal cipher]]) – the second cipher would completely undo the first. If an attacker were to recover the key through [[cryptanalysis]] of the first encryption layer, the attacker could possibly decrypt all the remaining layers, assuming the same key is used for all layers. To prevent that risk, one can use keys that are [[statistical independence|statistically independent]] for each layer (e.g. independent [[random number generator|RNGs]]). Ideally each key should have separate and different generation, sharing, and management processes. ==Independent Initialization Vectors== For en/decryption processes that require sharing an [[Initialization Vector]] (IV) / [[Cryptographic nonce|nonce]] these are typically, openly shared or made known to the recipient (and everyone else). Its good security policy never to provide the same data in both plaintext and ciphertext when using the same key and IV. Therefore, its recommended ''(although at this moment without specific evidence)'' to use separate IVs for each layer of encryption. ==Importance of the first layer== With the exception of the [[one-time pad]], no cipher has been theoretically proven to be unbreakable. Furthermore, some recurring properties may be found in the [[ciphertext]]s generated by the first cipher. Since those ciphertexts are the plaintexts used by the second cipher, the second cipher may be rendered vulnerable to attacks based on known plaintext properties (see references below). This is the case when the first layer is a program P that always adds the same string S of characters at the beginning (or end) of all ciphertexts (commonly known as a [[Magic number (programming)|magic number]]). When found in a file, the string S allows an [[Kernel (operating system)|operating system]] to know that the program P has to be launched in order to decrypt the file. This string should be removed before adding a second layer. To prevent this kind of attack, one can use the method provided by [[Bruce Schneier]]:<ref>{{cite book |last1=Schneier |first1=Bruce |title=Applied Cryptography, Second Edition: Protocols, Algorithms, and Source Code in C |date=30 March 2015 |publisher=Wiley Computer Publishing |pages=368 |isbn=9781119096726 |url=https://books.google.com/books?id=VjC9BgAAQBAJ&q=15.8+Combining+Multiple+Block+Algorithms&pg=PA368}}</ref> * Generate a random pad R of the same size as the plaintext. * Encrypt R using the first cipher and key. * [[XOR]] the plaintext with the pad, then encrypt the result using the second cipher and a different (!) key. * [[Concatenate]] both ciphertexts in order to build the final ciphertext. A cryptanalyst must break both ciphers to get any information. This will, however, have the drawback of making the ciphertext twice as long as the original plaintext. Note, however, that a weak first cipher may merely make a second cipher that is vulnerable to a [[Chosen-plaintext attack|chosen plaintext attack]] also vulnerable to a [[Known-plaintext attack|known plaintext attack]]. However, a [[block cipher]] must not be vulnerable to a chosen plaintext attack to be considered secure. Therefore, the second cipher described above is not secure under that definition, either. Consequently, both ciphers still need to be broken. The attack illustrates why strong assumptions are made about secure block ciphers and ciphers that are even partially broken should never be used. ==The Rule of Two== The '''Rule of Two''' is a data security principle from the [[National Security Agency|NSA's]] Commercial Solutions for Classified Program (CSfC).<ref>{{cite web |url=http://www.nsa.gov/ia/programs/csfc_program/ |title=Commercial Solutions for Classified Program |publisher=US National Security Agency |access-date=24 December 2015 |quote= |archive-url=https://web.archive.org/web/20151225183650/https://www.nsa.gov/ia/programs/csfc_program/ |archive-date=25 December 2015 |url-status=dead }}</ref> It specifies two completely independent layers of cryptography to protect data. For example, data could be protected by both hardware encryption at its lowest level and software encryption at the application layer. It could mean using two [[Federal Information Processing Standards|FIPS]]-validated software cryptomodules from different vendors to en/decrypt data. The importance of vendor and/or model diversity between the layers of components centers around removing the possibility that the manufacturers or models will share a vulnerability. This way if one components is compromised there is still an entire layer of encryption protecting the information at rest or in transit. The CSfC Program offers solutions to achieve diversity in two ways. "The first is to implement each layer using components produced by different manufacturers. The second is to use components from the same manufacturer, where that manufacturer has provided NSA with sufficient evidence that the implementations of the two components are independent of one another."<ref>{{cite web |url=https://www.nsa.gov/Portals/70/documents/resources/everyone/csfc/capability-packages/MACPv2_1.pdf/ |title=Mobile Access Capability Package |publisher=US National Security Agency |access-date=28 February 2020 |quote=}}</ref> The principle is practiced in the NSA's secure mobile phone called Fishbowl.<ref name=":0">Adams, David / Maier, Ann-Kathrin (2016): BIG SEVEN Study, open source crypto-messengers to be compared β or: Comprehensive Confidentiality Review & Audit of GoldBug, Encrypting E-Mail-Client & Secure Instant Messenger, Descriptions, tests and analysis reviews of 20 functions of the application GoldBug based on the essential fields and methods of evaluation of the 8 major international audit manuals for IT security investigations including 38 figures and 87 tables, URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf β English / German Language, Version 1.1, 305 pages, June 2016 (ISBN: 110368003X β DNB: 2016B14779)</ref> The phones use two layers of encryption protocols, [[IPsec]] and [[Secure Real-time Transport Protocol]] (SRTP), to protect voice communications. The Samsung [[Galaxy S9]] Tactical Edition is also an approved CSfC Component. ==References== {{Reflist}} ==Further reading == {{refbegin}} * "Multiple encryption" in [https://www.ciphersbyritter.com/GLOSSARY.HTM#MultipleEncryption "Ritter's Crypto Glossary and Dictionary of Technical Cryptography"] * Confidentiality through Multi-Encryption, in: Adams, David / Maier, Ann-Kathrin (2016): BIG SEVEN Study, open source crypto-messengers to be compared β or: Comprehensive Confidentiality Review & Audit of GoldBug, Encrypting E-Mail-Client & Secure Instant Messenger, Descriptions, tests and analysis reviews of 20 functions of the application GoldBug based on the essential fields and methods of evaluation of the 8 major international audit manuals for IT security investigations including 38 figures and 87 tables, URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf β English / German Language, Version 1.1, 305 pages, June 2016 (ISBN: 110368003X β DNB: 2016B14779). * A "way to combine multiple block algorithms" so that "a cryptanalyst must break both algorithms" in Β§15.8 of ''Applied Cryptography, Second Edition: Protocols, Algorithms, and Source Code in C'' by Bruce Schneier. Wiley Computer Publishing, John Wiley & Sons, Inc. * S. Even and O. Goldreich, On the power of cascade ciphers, ACM Transactions on Computer Systems, vol. 3, pp. 108β116, 1985. * M. Maurer and J. L. Massey, Cascade ciphers: The importance of being first, Journal of Cryptology, vol. 6, no. 1, pp. 55β61, 1993. {{refend}} {{DEFAULTSORT:Multiple Encryption}} [[Category:Cryptography]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Blockquote
(
edit
)
Template:Cite book
(
edit
)
Template:Cite web
(
edit
)
Template:Comma separated entries
(
edit
)
Template:Main other
(
edit
)
Template:Refbegin
(
edit
)
Template:Refend
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)