1 / 69

Chapter 7 - Authentication Defined: Verification of the claimed identity of an entity (a person

Chapter 7 - Authentication Defined: Verification of the claimed identity of an entity (a person or a system) or of the origin of information such as a message. Process: 1. Obtain an identifier (name/address) and an authenticator (token,

layne
Download Presentation

Chapter 7 - Authentication Defined: Verification of the claimed identity of an entity (a person

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7 - Authentication Defined: Verification of the claimed identity of an entity (a person or a system) or of the origin of information such as a message. Process: 1. Obtain an identifier (name/address) and an authenticator (token, password, biometric characteristic) from the subject user/system. 2. Compare the authenticator with the stored or computed information that is associated with the entity being authenticated. 3. Determine that the authenticator presented and the stored or computed authenticator are the same. Both entity (user & system) and message authentication and how cryptography is used to support authentication will be covered. Authentication & Hash Functions

  2. Password Authentication Most common means of user authentication with a significant range of capabilities, strengths, and weaknesses. Login Prompt User Login Process Login Response Password File Y N Compare OK User id Password Reject User 1 User 2 User 3 . . . User n Zionko dorkum Alice . . . gee9me < User 2, dorkum > Authentication & Hash Functions

  3. Login Process During a boot process or at a command line prompt, the operating system initiates a login process that prompts the user: System challenge: Please Login User Response: <User_Identifier, Password> < > denotes user entered information The user_identifier is used as an index into a password file that holds valid user names and password pairs. The password returned from the file is compared to the password entered by the user and on a match, the user is authenticated and granted access to the system. The question is how secure is this process and how can it be compromised? These issues were briefly discussed in Chapter 2. Authentication & Hash Functions

  4. Password Security The main advantage of password systems are their ubiquity and ease of use. However, there are potential problems with password systems: 1. Composition of the password (too few symbols). 2. Length (too short). 3. Lifetime (too long). 4. Source (if simply generated may be simply broken). 5. Ownership/Sharing (you own it, don’t share it). 6. Initial generation/distribution (is it well protected?). 7. Storage (there for all to see?). 8. Transmission (in the clear – can it be sniffed?). Authentication & Hash Functions

  5. Password Security Factors Composition:The symbols used to create the password. Typically: 10 numeric digits for ATM PINs (personal id number). 95 printable ASCII symbols for computers (varies). Users can construct many combinations, some strong, some weak. Particularly unacceptable are: Dictionary words and certain permutations (e.g., backwards). Any personal names/dates (e.g., wife, pets, birthdays, etc.). All alpha or all numeric (use mixed). Single case (use mixed case). Authentication & Hash Functions

  6. Password Security Factors Length:Taken together, composition & length establish the limits for assessing the difficulty in exhaustive attacks on passwords. For example, using 95 characters and length = Length = 1 implies only 95 possible passwords. The password search space is: N = SL; where: N = Number of possible passwords S = Number of symbols (characters) in the password alphabet L = Length of the password in symbols For S = 95, L = 7; N = 957 ~ 7 x 1013 However, this also assumes all password constructs are equally likely and as we have seen that is a bad assumption. Authentication & Hash Functions

  7. Password Security Factors On average, we expect an attacker would have to attempt 1/2 of the possible passwords to find the right one. Assume passwords can be attempted at 106, 107, and 108 per second. Then: Time 1000 = ((7 x 1013)/(106))(1/60x60x24) = 810.2 days Time 100 = ((7 x 1013)/(107 sec))(1/60x60x24) = 81 days Time 10 = ((7 x 1013)/(108 sec))(1/60x60x24) = 8.1 days Clearly, these times are all within the capability of modern computers, especially parallel machines. The times are even faster if the password is not randomly constructed and/or does not use the full character set, etc. Authentication & Hash Functions

  8. Password Security Factors Lifetime:Passwords should have a limited valid lifetime. The most effective would be a one-time password that is only valid for a single use. Some password systems have this capability. Valid times are based on a balance between the expected threat and the value of the information being protected. Typical times are 3-12 months, with 6 months being typical, more often for system administrators. Passwords should be changed after first issued, when compromised or shared, or as requested by a system administrator. Source: Passwords should be algorithmically generated by a computer where the algorithm has been tested against known hacking tools (e.g., CRACK, l0phtcrack). Authentication & Hash Functions

  9. Password Security Factors Ownership:A password belongs to a single individual and should never be shared. A shared password is a compromised password and if sharing is essential, change it after sharing is over. Distribution: Passwords should be distributed in a secure manner with positive identification of the user (to avoid social engineering). Storage: Passwords appear in at least two places; stored on systems, passed over the network. Two threats are obvious: Unauthorized disclosure of the password Unauthorized replacement The first is rather obvious, but if an adversary can replace a password, they can masquerade as a legitimate user. Authentication & Hash Functions

  10. Password Security -Transmission Password system designs in order of increasing protection: Clear text passwords - threat is sniffing. Any system with access to the transmission channel can run a network interface in promiscuous mode and read every password flying by or any directed to the system the sniffer is installed on. Encrypted passwords - threat is capture, off-line cracking, and/ or re-play at a later time. Hashed passwords - threat is capture, off-line guessing, and/or re- play - harder than dictionary attacks - requires generation of passwords, hash, and compare. Hashed with a random number - same as hashed, but more difficult to guess (longer, more random source) One-time hashed or encrypted – used once and changed - most secure. Authentication & Hash Functions

  11. Password Security – Storage Protection Methods Methods of storage in the order of increasing protection are: 1. Password stored in clear text in the system administrator account. 2. Password stored in clear text in an account only accessible by the login or password management process (no administrator access). 3. Password is encrypted and stored in a publicly accessible file. 4. Password is encrypted and stored in a file only accessible by a system administrator. 5. Password hashed and hash stored, not password. 6. One-time hashed password - as in transmission - best method Clear text passwords stored or transmitted are extremely vulnerable. A network sniffer can capture transmitted passwords. A privileged user (e.g., system administrator) can read the file. Authentication & Hash Functions

  12. Passwords - Clear Text Transmission & Storage Authentication & Hash Functions

  13. Encrypted Password Protection Uses a process to encrypt and store the password. Login process encrypts password entered by the user and compares it to the encrypted value, on match the user is authenticated. Variation 1: Two-way (reversible) encryption, public file. The password is encrypted and stored in a public file. Login process encrypts the password using the user_name or a fixed number as the key and compares the stored value with the user supplied value. If publicly accessible, any user with system access can obtain the file and perform an off-line attack using the standard encryption and a dictionary. That is, encrypt a large list of dictionary words and search for a match on the encrypted password file. Often returns breaks in a few hours. Authentication & Hash Functions

  14. Passwords - Encrypted Storage Attack Authentication & Hash Functions

  15. Encrypted Password Protection Variation 2: Encrypt and store in a non-public file accessible only to the system administrator. In this case, an adversary must not only gain access, but must also gain system administrator (root) access. Better, but many systems have been compromised by attacks where the adversary gains root privileges. In either variation 1 or 2, the encryption key must be protected. Variation 3: One-way (non-reversible) hash where the password is not stored. Only the hash is stored. A hash is a one-way keyless transform that is infeasible to invert. A password manager creates a hash of the user’s password and stores it. When a user logs in, the same hash algorithm creates a new hash on the user supplied password and it is compared to the stored hash value. Authentication & Hash Functions

  16. Unix Passwords Uses a modified form of the DES algorithm operating like a hash. Also uses a “salt” that is a random number so two users with the same password do not produce the same hash. The salt is a 12-bit random number derived from the system clock when the password is created. The password is 8 characters in length (56 bits) and used as a key with the padded salt as a second input. The algorithm performs 25 encryptions and produces an 11 character output. The output is stored along with the 12-bit salt. On login, the salt is accessed, combined with the password, the encryption is run, and the output compared to the 11 character stored value. The key is not stored; only the salt is stored. Still a persistent password. Better method is a one-time password and it is much better. Authentication & Hash Functions

  17. One-Time Password - Lamport’s Method Typically used for remote login to a server or network login, so there are two sides, a client and a server. The client enters a passphrase. Servers maintain a database of: client username, integer n that decrements for every authenticated login, and a hashn(passphrase). Where hashn = hash(hash(hash(hash….hash(passphrase)…)). The client user chooses a passphrase and a number n (1 < n < 1000). The client computes m1 = hash(passphrase), m2 = hash(m1), … n times to finally produce mn = hashn(passphrase). This value is stored at the server. The client sends the server n and mn = hashn(passphrase). Authentication & Hash Functions

  18. One-Time Password - Lamport’s Method To login from the client to the server, the client prompts the user for a username and the passphrase. The username is sent to the server. The server response returns the current value of n, say 100. This value is decremented after every use. The workstation computes hashn-1(passphrase) and sends the result to the server. Servers accepts hashn-1(passphrase) and hash it once more producing hashn(passphrase) and compares it to the stored value for the user. On match, the user is authenticated. The received value, the hashn-1 (passphrase), is used to replace the current value hashn(passphrase). This is a one-time password that can’t be re-played by an adversary. Further, the passphrase is never disclosed over the connection between the client and the server. Authentication & Hash Functions

  19. Lamport’s Method - Example ClientServer Setup: Select username, n = 100, and passphrase Compute hash100(passphrase) Send username, n, hash to server -------- Store username, n, hash First use: Username login request sent to server -- Get n, compute n-1 (99), save, return 99 to user Enter passphrase, compute hash99, send to server ----------- Compute hash99+1, compare to original stored hash Next use (hash98) and so on Result is a one-time password, never sent in the clear! Authentication & Hash Functions

  20. Lamport’s Method - Enhanced If n reaches 1, a new password is selected and the hash initialized. Add a salt, a random number that is concatenated with the passphrase to produce hashn(passphrase|salt). Now n, the salt, and the hashn(passphrase|salt) is sent to the server. On login request, the server returns the current n, and the salt. The benefit is the same passphrase can be used on several systems, each with a different salt. When n reaches 1 and a new hash must be generated, the passphrase can be re-used with a new salt. The salt prevents an adversary from pre-computing hashn for dictionary words and values of n from 1 to n, then accessing the server database, and comparing hashes with the stolen passphrase hashes. Authentication & Hash Functions

  21. Lamport’s Method - S/Key S/key is an extension of the Unix “salt” method based on Lamport's algorithm and is now distributed with most Unix systems. Generates multiple passwords, each with an iteration count so no two are alike. A particular password is good for a single login Consists of four processes: ‘Key’ uses an iteration count, a salt (called a seed), and a secret pass phrase and generates a one-time password hashed n times, where n is the iteration count. ‘Keyinit’ initializes and change passwords, iteration counts, & seeds. ‘Keyinfo’ returns the current iteration count & seed. ‘login & su’ contain code to recognize S/key passwords. Authentication & Hash Functions

  22. S/Key - How It Works Seed is generated by the client and is 2 letters and 5 digits (ba65867) A secret passphrase is entered by the user (e.g., a six-word phrase - like GRP DEOS BUND CHAO SEEN NEEP). An iteration count from 1-100 is entered (user selected & determines the number of hash rounds to apply). Password is generated using the concatenation of the seed and the pass phrase, applying a one-way function (e.g., MD5 hash). The number of times the hash is applied is = iteration count. The one-way function results are significantly different between each iteration - knowing one will not aid in predicting the next one. The environment you generate the password on must be secure If a local client - no sniffers. Must have a secure connection if the local client can’t do this computation (e.g., an X-terminal). Authentication & Hash Functions

  23. One-Time Password - S/Key There is now a password stored on your machine (the pass phrase is not). You must get the password to the server. Run “keyinit” on the server. Enter the seed and iteration count used, copy the password generated on your secure machine to the host. The secret passphrase is never disclosed over the connection. Only the seed, iteration count, and hash password have been sent. This initializes/synchronizes the server to the client system. An adversary could get the seed, iteration count, and hashed password, but this is not enough to predict the next hashed password. Authentication & Hash Functions

  24. One-Time Password - S/Key - Key & Keyinit Client Side Server Side Username, Salt Username, Salt, Count File Hash Iteration Count Pass- word file Secret Passphrase (not stored, not passed, system must be secure when entered - no internal sniffer) Client password for a specific hash count Authentication & Hash Functions

  25. One-Time Password - S/Key - Key & Keyinit Client Side Server Side Login Process Username Username, Salt, Count File Login Request Salt, Count Secret Passphrase Compute new hash (for current iteration count) Verify (compute hash n) Pass- word file Password Hashed password for a nth iteration count Authentication & Hash Functions

  26. Microsoft NT Passwords - A Final Note Windows NT supports 14 character passwords (~ 5 x 1033 possibilities for a 256 character symbol set). Of course you can’t use all the characters (duh!) & not everyone picks 14 character passwords and they often pick easy passwords (and there is no enforcement capability). So what.. We knew that. What about the form of the stored password? NT stores the passwords as MD4 hashes for two 7-character passwords. So, it is only about twice as difficult to find a 14 character password that produces a specific hash (guess a 7 bit partial password and compute the hash) than it is for only a 7 bit password alone. Authentication & Hash Functions

  27. Kerberos Authentication Kerberos is an authentication protocol named for the watchdog of Greek mythology that guarded the gates of Hades. The dog is depicted with three heads, a serpent’s tail, a mane of snakes, and a lion’s claws (makes you wonder who is guarding the exit!). First developed in the 1980’s, maintained, and distributed by MIT originally for Unix systems – also now incorporated in Windows 2000 & XP. Specifications are open – code is another matter. Kerberos is a authentication protocol for client/server applications (usually remote logins) - also supports message integrity and data confidentiality. Kerberos uses symmetric key encryption which generally doesn’t support authentication. Kerberos is an exception to this observation. Authentication & Hash Functions

  28. Kerberos Authentication Kerberos provides services to users through two primary service mechanisms – a key distribution service and a ticket-granting service. Consider the following players: Alice and Bob (Bob is most often a remote service rather than a person). Alice wants to establish mutually secure authentication and then send and receive secure transmissions to/from the Bob service. A Kerberos Key Distribution Server (KDS) is used to manages and distribute the keys used by Alice and Bob and also supports a Ticket Granting Service (TGS) that issues time-dependent tickets to Alice and Bob for secure authentication and communication. This is a three-headed system with two principals (Alice & Bob) and a trusted third party, the Kerberos KDS. Authentication & Hash Functions

  29. Kerberos Initialization Use requires a Kerberos client and enrollment in the KDC. Once enrolled, the KDC creates a database entry for the user that contains a long term key for each user based on the users-name. The key is derived by creating a one-way hash of the user’s password. This is one of the potential vulnerabilities of Kerberos if the user selects a poor password! (see Stallings pg. 415-416 for details). The long term key is stored on the KDC, but is not stored on the user’s system. It is re-created each time it is needed. This can create some difficulties when users change their passwords so it is not a good idea to use the same password for other applications. Authentication & Hash Functions

  30. Kerberos – Authentication Request For Alice to authenticate to Bob, she presents her password to the local Kerberos client and it accesses the KDC. Alice’s client sends a Ticket-granting Ticket request to the KDC to indicate she is an authorized user. It contains both names, Alice and Bob and is DES encrypted with Alice’s password-derived key. Alice’s Ticket-Granting Ticket, Request to authenticate to Bob, Contains Alice’s username and Bob’s name – encrypted with Alice’s long term DES key. Alice KDC Authentication & Hash Functions

  31. Kerberos – KDC Response to Alice Alice’s client sends an application request to Bob that contains the ticket provided by the KDC containing Alice’s name, the session key, and expiry time all encrypted with Bob’s long term key and An authenticator encrypted with the session key. Bob decrypts the ticket finding Alice, time, And the session key and uses the session key to decrypt the authenticator – knows Alice knows the session key. Bob checks the time to see if it is valid. At this point Bob has authenticated Alice. Alice Bob Authentication & Hash Functions

  32. Kerberos – Bob’s Response to Alice Bob adds one to the time Alice sent, encrypts it with the session key and sends it back to Alice. Alice decrypts with the session key and checks the time to see if the time is her time plus one. At this point Bob has authenticated to Alice. From this point on Alice and Bob can exchange Messages. Alice can log on to Bob and use service. Alice Bob Authentication & Hash Functions

  33. Kerberos – Weaknesses If the password Alice uses to generate the key is weak, it could be easily broken off-line. The KDC is a trusted system. If it is compromised all the long-term keys are compromised. The KDC can be a performance bottleneck, but it is possible to replicate KDCs. It may be possible to cache and re-play old authenticators. Although time stamps are used, re-play is possible during the life of a ticket. If some history of used time stamps is retained, this can be detected. Kerberos is widely used in the scientific community and is now supported in Windows 2000 and XP. Authentication & Hash Functions

  34. Message Authentication Process to ensure: A message (data file) has not been altered in transit or while it was stored, and/or the originator of the message can be identified. Methods used to provide message/file authentication: Encryption of the message Message Authenticating Codes (MAC) Digital Signatures (hash functions) These must be capable of delivering some token that validates the authenticity of the message or file. Authentication & Hash Functions

  35. Authentication by Encryption If we apply Ek(P) = C at the source and Dk(C) = P at the receiver and Use a strong, well-protected, secret key and algorithm We would expect the decrypted value of P to be the same as the encrypted value of P. BUT, assume, an adversary intercepts C and changes one, or more, characters (bits). Running Dk(C) will produce a plaintext result. Most likely P will be altered in some obvious way (e.g.,misspelled words). Trouble is - how do we know for sure? The typist at the source may have made the error or the channel may have been corrupted. There is no way of knowing for sure! At best we are uncertain. Result -- Encryption alone is insufficient to authenticate! Authentication & Hash Functions

  36. Message Authenticating Code (MAC) Conceptually - Compute a cryptographic checksum over the body of the message, encrypt it with a shared key, append it to the message, decrypt it at the destination, re-compute the checksum from the message, and compare the two checksums. If they compare - OK, if not - reject. Either the checksum or the message has changed. Characteristics of a MAC: Created from the message MAC = f(M) Much smaller than the message MAC<< M Knowing MAC does not reveal the message since the MAC is encrypted (so an adversary cannot simply change a message, compute a new MAC, and append it to the altered message). The message may/may not be encrypted depending on whether it needs to be kept secret or not. MACs ensure integrity, not secrecy. Authentication & Hash Functions

  37. Generating a MAC Concept: Similar to error-detecting codes, like a Frame Check Sequence (FCS) or Cyclic Redundancy Check Character (CRCC). Given a message: 1. Represent the message as a polynomial: 10011 = 1 x 24 + 0 x 23 + 0 x 22 + 1 x 21 + 1 2. Select a second polynomial < M, say 101 = 1 x 22 + 0 x 21 + 1 3. Divide the message by the 2nd polynomial, mod 2 10011/101 = 19/5 = Q = 3, R = 4 4. Append R to the message and send = 10011|100 Authentication & Hash Functions

  38. Receiving a MAC 1. Receive 10011|101 2. Separate, save MAC, re-compute MAC using same algorithm 10011/101 = 19/5 = Q = 3, R = 4 3. Compare to received MAC. Same = OK, different = reject. MAC changed = 10011/100 = 19/4; Q = 4, R = 3 Message changed = 11011/101 = 27/5 ; Q = 5, R = 2 Trouble is, 25 = 32 is the range of legal messages. Any message divisible by 5 with R = 4, would pass (e.g., 29, 24, 19, 14, 9, 4 ). In real systems, the polynomial selected for the divisor has a set of properties that preclude this – but is not secure. Authentication & Hash Functions

  39. Diagram - Message Authentication Code (MAC) Authentication & Hash Functions

  40. Diagram - Variation on MAC - One-Way Hash Authentication & Hash Functions

  41. MAC & One-way Hash Differences: MAC uses a shared secret key (must distribute/exchange the secret key). Hash uses public/private key pair - no private key exchange. Both methods support integrity - more or less equally well. MAC won't do authenticity of source (i.e., signature) because the secret key is shared - more than one party knows the key. Hash can do signature because the secret (the private key) is not shared. We do need to understand hash functions to accept this. Authentication & Hash Functions

  42. Hash Functions - Authentication & Integrity H = f(M) Where: M = Variable length message input (any length) f = hash function or hash algorithm (one-way function) H = hash value output (typically 128 to 160 bits in length) Typical hash functions: Message Digest 2,4, & 5 (MD2, MD4, MD5) Secure Hash Algorithm (SHA, SHA1 - Federal standard) RIPEMD-160 (European standard) Stallings discusses all of these. Authentication & Hash Functions

  43. Hash Functions - Requirements 1. Accept any length message as input. 2. Produces a smaller fixed size output (128/160 bits). 3. Easy (fast) to compute H for arbitrary length messages. 4. H = f(M) is a one-way function (hard to invert). 5. H = f(M) is resistant to weak collisions (given H1= f(m1), hard to find any other mn that produces H1 6. H = f(M) is resistant to strong collisions (hard to find any two different messages that produces f(mn) = f(mm) The first three: Practical properties associated with generality (ability to handle a large class of messages), storage and by efficiency (does not significantly increase the length of the transmitted or stored message), and efficiency (fast, simple to compute). The other three are not so obvious - discuss separately. Authentication & Hash Functions

  44. Requirement # 4 - One Way Functions For a specific hash function H = f(M), it is not feasible to find: M = f -1(H) That is, the hash cannot be easily inverted to find the message. This is a fundamental property of all one-way functions. Example: For a message M of n blocks, mn each block = 64 bits. Form H = f (m1|m2 m3|m4  …... mn-1|mn) (a form of parity). This forms a single 128 bit output from an arbitrary message. If the message is not an even multiple of 64 bits, it can be padded. It is not feasible to recover the components of the message. However, this is not a good hash algorithm. It is easy to create a second message with the same output (fails the collision test). Authentication & Hash Functions

  45. Requirement # 5 - Weak Collision Resistance For a specific message M, it is not computationally feasible to find another message N  M, but where H = f(M) = f(N). That is, given a message, it not feasible to find another message that produces the same hash. Otherwise it would be possible to forge messages as follows: 1. Intercept the original plaintext message and the encrypted hash. 2. Run the hash algorithm on the plaintext message to recover the original unencrypted hash. 3. Create a new (forged) message that produces the same hash. 4. Replace the original message with the forged message and the original encrypted hash. A receiver will decrypt the hash, run a new hash on the message, find that they compare, and assume the message is authentic. Authentication & Hash Functions

  46. Weak Collision Resistance Given: the hash of a document: M H=f(M) Find any other document N where H=f(N) = f(M) N H=f(M) = f(M) Could allow interception in transit and replacement of M with N, but would test OK at the destination – forgery. Authentication & Hash Functions

  47. Requirement # 6 - Strong Collision Resistance For any pair of messages M & N, it is not computationally feasible to create M & N such that H = f(M) = f(N). This is a more general requirement than the weak collision requirement since it must hold for any pair of messages an adversary might create (one saying one thing and a second that says the opposite - another type of forgery). Required to avoid a class of attack called the "birthday attack", so named because of the birthday paradox. If two messages produce the same hash value (the digest) then the digests have collided. Hash algorithms must either avoids collisions or require enough resources to make finding a collision computationally infeasible. Authentication & Hash Functions

  48. Strong Collision Resistance Given: Create two documents: M H=f(M) N H=f(M) = f(M) Where the hashes of two documents M & N = H=f(N) = f(M) Could allow forgery at document creation time such that M is valid, but could be replaced by invalid N after hashing, but would test OK at the destination – another type of forgery. Authentication & Hash Functions

  49. Collisions Hash algorithms map a very large number of messages into finite digests (e.g., 128/160 bits), so collisions are possible. The question is, are they probable? The answer is no. 128 bits will produce 2128 possible digests ~ 3.4 x 1038. If we create 3.4 x 1038 + 1 different input messages, then at least 1 collision will occur since the additional document is one more than the digest space and would have to map to an existing digest. This occurs iff the hash algorithm produces 2128 different digests for 2128 different input documents. Realistic algorithms are not this good, producing collisions with fewer documents. Assume the algorithm only produces 2127 different digests for 2128 different input messages. Then, one collision has occurred. Authentication & Hash Functions

  50. Security of Hash Functions Brute force attacks are used to break hash functions. Since there is no key, the attack is on the hash digest, a 128/160 bit value. Thus, the difficulty of the attack is a function of the length of the digest. One-way and weak collision attacks are designed to take a specific message, the target message, and find a second message that produces the same hash. Windows passwords are broken this way. An adversary would have to produce a set of messages, compute their hash digests, and compare them to the original digest. The order of effort is 2n, where n is the digest length and we would expect to be successful, on average, after 2n/2 tries. For n = 128 or 160 bits this is a formidable computational effort. Authentication & Hash Functions

More Related