Which of the following is least likely to ensure security through the application of cryptographic hash? (Source: Wentz QOTD)
A. Establish HTTP sessions by Digest Access Authentication
B. Persist passwords with pepper
C. Detect error using odd parity
D. Enforce accountability through digital signature

Kindly be reminded that the suggested answer is for your reference only. It doesn’t matter whether you have the right or wrong answer. What really matters is your reasoning process and justifications.

My suggested answer is C. Detect error using odd parity.

Parity check is typically not considered a cryptographic hash even though it is a checksum and can be treated as a simple hash table with two buckets (even or odd). Cryptographic hash functions pursue high degree of uniqueness, but parity check has two items in the hash table. In other words, the parity check has a high collision rate.

Parity Bit

A parity bit is prepended or appended to a bit sequence based on the number of one (1) as odd or even to detect an error. An odd parity check tells the recipient that the number of one (1) in the bit sequence should be odd.

For example, a 7-bit sequence, 0000111, has three ones (1s). In an odd parity system, the parity bit is set to zero (0) so that the number of one (1) becomes odd. If the parity bit is prepended to the 7-bit sequence, it forms a new 8-bit sequence, 1000111 (or 1|000111). When the recipient receives a bit sequence of 00000011, he can tell there’s something wrong because the number of one (1) should be odd.

Salt and Pepper

Salt and pepper are password persistence strategies that rely on the hash.

• A “salt” is generated randomly and associated with EACH password. The user’s password is not saved in the repository but the salted password.
  Salted password = Hash(salt | password)
• A “pepper” is also a random number, but it is applied to EVERY password, stored secretly and separately apart from the password repository.
  Peppered password = Hash(pepper | salt | password)
  The symbol ‘|’ stands for concatenation.

Salted passwords are resistant to the rainbow table attack, but they still can be crackable because the salt is stored with the user’s password together. For example, if your shadow file (/etc/shadow) is stolen, the hacker can apply cryptanalysis to the password repository on his local machine.

Pepper adds another level of protection to salted passwords. The ‘pepper’ is typically stored in a location different from the one of the password repository and kept secret. It is applied to EVERY password to calculate the hash of a password.

HTTP Digest Access Authentication

HTTP Digest Access Authentication is used for the browser to authenticate to the web server through HTTP. It’s natively supported by the web server and browser compliant with RFC 7616, instead of web applications.

The browser calculates the digits as a response using the following formula:
Digest = Hash( username | password | nonce | HTTP method | URI)

The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value and might indicate that username hashing is supported. A valid response contains an unkeyed digest of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear, and the username can be hashed, depending on the indication received from the server. (RFC 7616)

Digital Signature

The digital signature can be a message digest or hash encrypted by the sender’s private key.

Reference

• Digest access authentication
• HTTP Digest Access Authentication
• Pepper (cryptography)
• Parity bit
• Odd Parity
• Password Hashing: add salt + pepper or is salt enough?
• Would You Like Pepper on That Hash?
• Rainbow table
• Character Parity