As block ciphers are intended to process data by blocks (groups of several bytes), there are
different ways of using a block cipher when encrypting multiple blocks. A file is composed of a
series of blocks, each block consists of several bytes, these blocks ARE NOT processed
simultaneously by the cipher. They are rather processed according to a specific scheme defined
by the cipher mode.
FIPS 81 has defined four (4) standard cipher confidentiality modes that can actually be applied to
any block cipher and may be used in a wide variety of applications. The 4 modes specify how data
will be encrypted (cryptographically protected) and decrypted (returned to original form).
The modes included in this standard are:
- ECB Electronic CodeBook
- CBC Cipher Block Chaining
- CFB Cipher FeedBack
- OFB Output FeedBack
NIST Special Publication 800-38A (NIST SP 800-38A), in its recommendation for Block Cipher
Modes of Operation has defined a fifth mode:
- CTR Cipher Counter Mode
Our development team has currently implemented two cipher modes in 96Crypt. They are namely
CTR and CBC mode. Cryptographic experts agree with our selection of these 2 modes considered
very well suited for security and confidentiality.
However, the cipher and its cipher mode provide a high degree of confidentiality but unfortunately,
without any means of message integrity. As confidentiality-only is a serious security hole that
unfortunately many cryptographic applications omit in their design, it was a must to include a MAC
in 96Crypt in conjunction with both CTR and CBC cipher modes.
MAC, (Message Authentication Code), is a symmetric approach to check the integrity of information
transmitted over or stored in an unreliable medium. Data integrity check is a MUST in the world of
open computing and communications. Mechanisms that provide such an integrity check based on a
secret key are usually called "message authentication codes" (MAC). Typically, message authentication
codes are cryptographic checksums on data and are used between two parties that share a secret
key (password) in order to validate the authenticity of information transmitted between these parties.
The computation of a MAC requires the use of a MAC algorithm and a secret key.
When a message (file) is EnCrypted, using a secret key, and sent to a second party, the selected
block cipher insures the message confidentiality so that NO man-in-the-middle would access the "plain"
message content. However, a man-in-the-middle could still intercept the message, modify/tamper
with it (without necessarily reading the content) and send it back to the second party.
If a MAC mechanism is not implemented, the second party would use the shared secret key to DeCrypt
the message that would no longer be authentic. This may lead to serious security issues.
However, with a MAC implemented in the application like in 96Crypt, the second party detects immediately
a tampered message so that the whole integrity of the message is preserved.
Cipher blocks and cipher modes provide confidentiality to keep the adversary from reading the "plain"
message, while MAC adds integrity check and prevents the adversary from modifying/manipulating
the message content.
The EnCryption function requires a password input by the user. The MAC function requires a user
password as well. Both user-provided secret passwords arbitrary in length are converted into fixed-length
output keys using HASH and/or HMAC-HASH algorithms.
In order to reduce complexity for the user to input two different passwords, 96Crypt uses a special
multi-round HASH/SALT function to generate a second fixed-length key from the first user input password.
This second internally generated key is then used as the input key for the HMAC-HASH authentication
scheme in either CTR or CBC mode.
We begin by computing the MAC of the message then we EnCrypt this message (file) together with
its MAC result. The reverse cycle is processed during DeCryption, where first we DeCrypt the
message (file) based on the user input secret password, then we check its MAC authentication.
A "MAC Failure" is generated in case of a tampered message (file).
This method is trusted by many cryptographic experts.
- 1. CTR mode + MAC
Counter-mode EnCryption (CTR mode) was introduced by Diffie and Hellman already in 1979, It
was defined in NIST SP 800-38A and is one of the best known modes. CTR mode has significant
efficiency advantages over the standard encryption modes and its tight security has been proven.
Typically, to EnCrypt using the CTR mode, one starts with a plaintext M (an arbitrary bit string; a file),
a key K (computed by HASHing the user-provided secret password), and an integer counter, nonce,
initially 0, and produces the string "ctr" as the n-bit string which encodes the number nonce.
The number nonce is incremented following each encryption. Typically, one transmits C along
with a string which encodes nonce.
Both nonce and "ctr" may be initialized or computed in various possibilities:
-1) The value ctr is derived from a nonce as described above, and the ciphertext specifies both
nonce and C.
-2) Same as in 1, except that no nonce-value is explicitly transmitted to the receiver because the
sender and the receiver maintain state and communicate over a reliable channel.
-3) Same as in 1, except that nonce starts at a random value between [0..2^(64 - 1)] instead of
starting from 0. (This is the mode used in 96Crypt)
-4) ctr is a random 128-bit string, selected afresh with each and every sent message.
-5) ctr is determined implicitly by other protocol elements, such as an accompanying sequence
number.
In all cases, the CTR mode remains a very secure and fast EnCryption mode to be used will all block ciphers.
In the following example, we will use the SERPENT block cipher with the SHA256 HASH function.
The CTR mode was selected and the used password is !HendriX PerformeD in 1969 WoodstocK!
The following 4096 byte file called 4096.bin initially containing all blanks (00H), will be EnCrypted
with the CTR mode.
Using an appropriate HEXADECIMAL file editor, let's flip the LSB of the 90th(Hex) byte from 0 to 1
making a whole byte flip from 46H to 47H ( 0100 0110 --> 0100 0111 )
Here's a detailed view of the above described manual bit-flipping when applied to the 90th(Hex)
byte of the file EnCrypted in CTR mode.
Although 1 single bit has been altered/modified, the EnCrypted file is NOT anymore authentic. When
the file is DeCrypted with the same user password !HendriX PerformeD in 1969 WoodstocK! it will
be immediately identified as having a "MAC Failure".
Looking inside the DeCrypted tampered file will reveal a file modification proving a file integrity alteration.
The 90th(Hex) byte was chosen randomly, any other byte-flipping still leads to the same conclusion.
- 2. CBC mode + MAC
Cipher Block Chaining (CBC mode) is another confidentiality mode initially defined in FIPS 81.
This mode, when it is properly used with a MAC authentication mechanism, provides a sure solution
to protect the confidentiality and integrity of your data.
In CBC mode, The encryption of each block depends upon the encryption of the previous block.
As a matter of fact, except for the first block, for each block of the file, the result of the previous
encryption is XORed with the next block before it is encrypted.
CBC is the mode used in IPSEC Internet Protocol SECurity, where security functions (authentication
and encryption) are implemented at the IP level of the protocol stack. It is optional for IPv4 and
mandatory for IPv6.
When multiple blocks in a typical message (file) were to be encrypted separately (like in ECB mode), an
adversary could easily substitute individual blocks, possibly even without detection. Furthermore, data
patterns in the plaintext "might" be apparent in the ciphertext.
CBC mode of operation has been defined to alleviate these problems by combining the basic cryptographic
algorithm with a feedback (XORing) of the information derived from the previous encrypted block.
As in the previous example, we have used the SERPENT block cipher with the SHA256 HASH function.
The CBC mode was selected and the used password is still !HendriX PerformeD in 1969 WoodstocK!
The 4096 byte file called 4096.bin initially containing all blanks (00H), will be EnCrypted with the
CBC mode.
Now, with an appropriate HEXADECIMAL file editor, we flip the LSB of the 90th(Hex) byte from 1 to 0
making a whole byte flip from 55H to 54H ( 0101 0101 --> 0101 0100 )
Here's a detailed view of the above described manual bit-flipping when applied to the 90th(Hex)
byte of the file EnCrypted in CBC mode.
Although 1 single bit has been altered/modified, the EnCrypted file is NOT anymore authentic. When
the file is DeCrypted with the same user password !HendriX PerformeD in 1969 WoodstocK! it will
be immediately identified as having a "MAC Failure" same as with the CTR mode described above.
However, aside the error message based on the HMAC-HASH calculation, the integrity of a tampered file
when EnCrypted with the CBC mode will be severly damaged after DeCryption. Looking in details inside
the DeCrypted tampered file reveals a serious file alteration that goes far beyond one single byte!.
The file will be perfectly restored to its original plaintext until the modified bit is reached. From that
level on, the file will undoubtedly show signs of an "adversary aggresion" as will NOT be correctly
DeCrypted, thus alerting the user on the file's integrity that has been severely compromised.
The 90th(Hex) byte was chosen randomly, any other byte-flipping still leads to the same conclusion.
It's never enough to insist on the importance of using a MAC (Message Authentication Code) with any
EnCryption mode even CBC or CTR that are incorrectly reputed as "strong enough" without a need
for a MAC.
Ciphers in any mode provide file confidentiality only. MAC complements the job by providing file integrity.
One without the other is a real serious security threat to your data.
Note:
When opening 96Crypt, it will auto-position on the last cipher mode selection that
was saved the last time 96Crypt was closed.
HASH Select
Copyright 2002 -
© eRightSoft