# Tag Info

It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks. For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message $m ... 7 The other answer is correct in general. However, if your messages are all exactly one block long (or all one block after padding), ECB is a secure MAC. A PRP looks like a PRF up to half its bit length, i.e. up to$2^{64}$blocks for AES. A secure PRF is a secure MAC of the same size. Thus, AES ECB used on 128-bit messages is a secure MAC as long as you use ... 7 First, the fact that the data is "easy" to guess (in the sense that an attacker has a one-in-2^32 or a one-in-2^64 chance of guessing correctly) doesn't mean much if the attacker has no way of checking if his guess is correct. Or at least, it's not a problem with the cryptography. Second, even if he does have that ability, the problem of protecting your ... 6 First the theoretical explanations: Integrity and authenticity are different goals to achieve, but both are achieved (for symmetric encryption) with a MAC. You should probably be using encrypt-than-MAC or an authenticated cipher unless you have very good reasons not to. No blanket statements can be made though. HMAC: HMAC is a often used construct. It ... 5 The attack is even more simple with RSA than with symmetric keys, because the asymmetric encryption key is assumed to be public. Let me tell you a story involving Alice, Bob and Mallory :). Alice wants to send a message to Bob using RSA. Alice encrypts the message using Bob's public key and sends it Mallory performs a Man-In-The-Middle attack, and ... 5 Yes, there are several ways in which Mallory could pretend to be Amy. One obvious way, which doesn't even involve Amy herself in any way, would be for Mallory to perform steps 1 and 2 of the protocol normally, as if he were Amy. Then, given Betty's nonce$n_b$, Mallory can start a second, parallel instance of the protocol, again pretending to be Amy, and ... 5 No, since finding$a$allows offline checking of passwords.$\:$No, although I can't back this part up. 4 I am wondering if using Skein or the Keccak hash algorithm in this construction (as a stream cipher) is secure: In the case of Skein and Keccak it should be secure. However, both of those have defined their own cipher modes which you should IMO prefer. (For speed and compatibility, if not security.) The Skein one is defined in section 4.10 of the ... 4 The access codes were recently leaked (by whom, I don't know). My Yubikey is listed and I can confirm that the access codes were necessary and sufficient to reprogram it. You can change or remove the access code as part of reprogramming too. The leak doesn't make the Yubikeys useless in the extremely unlikely event of Gox rising from the flames — no ... 4 Cryptography studies properties of information. Information, at least in discrete form (a sequence of bits) can inherently be duplicated. Inasmuch as a document conveys meaning, it can be expressed as a sequence of bits. If someone obtains a copy of the document, they can duplicate the sequence of bits and make other copies. It is impossible to prevent the ... 3 From RFC 4226: 7.4. Resynchronization of the Counter Although the server's counter value is only incremented after a successful HOTP authentication, the counter on the token is incremented every time a new HOTP is requested by the user. Because of this, the counter values on the server and on the token might be out of synchronization. ... 3 If you need a MAC, use a MAC. For example, HMAC which uses a hash function. Don't try to use a random hash function in your own scheme, because some such schemes are not secure. Reason to use/not use this data as input to the hash? (In the context of authenticity of data…) If you do have a secure MAC, any constant data will not affect the authenticity. ... 3 If you want$N$serial numbers, your serial numbers will have to use$n$bits for uniqueness, where$n = \log_2 N$. So if you have 100 bits to use for the serial, you could use 20 to get about a million serials and have 80 bits to use for a cryptographic MAC or signature. Now there are two approaches, the symmetric and the asymmetric. In the symmetric ... 3 Well, 32 bits is somewhat short, so one could just try ciphertexts. However, there is a much better attack. Choose M0 arbitrarily, let P be the CBC padding for Headers || CRC || M0, and choose M1 so that CRC( M0 || P || M1 ) = CRC(M0). Submit M0 || P || M1 to be encrypted, truncate the ciphertext to the length of encryptions of M0, and then output the ... 3 Yes, because Mallory can use Amy and Betty to get any encrypted nonce; Amy and Betty are oracles for Mallory. She just has to send the nonce she has to encrypt to either one of them and they perform the task for her (in another "authentication attempt", using step 1 & 2). Usually you protect against this kind of situation by performing an encryption ... 3 HMAC-SHA-256 is sufficient for up to 256 bit security. Confer e.g. NIST SP 800-107. This recommendation is based on the premise that collision attacks are infeasible against common uses of HMAC, and that you consequently only have to worry about primary pre-image attacks that attempt to recover the secret key (and use this for forging subsequent messages). ... 3 In a rolling code both the sender and the receiver always move forward in the sequence. If the sender has sent the$n$th code, then it will send the$(n+1)$th next. Contrarily, if the receiver has seen the$n$th code it will only accept the$(n+1)$th code or some later code. What happens if the sender is at another point in the sequence? Think of that ... 3 This is vulnerable to a length extension attack. Given a valid nonce/MAC, the nonce can be extended to forge a new valid nonce/MAC value. This is because$m_4$is appended to the end inside the outer hash. How this affects you will depend on how you validate your nonce. But in general, this is not a secure construction. There's probably more things wrong ... 3 The motivation, to me, is that in reality you can consider any router on the internet to be successfully executing an "intruder-in-the-middle" attack just by forwarding messages unchanged. After a successful execution of the identification scheme, Bob knows that someone on the channel is Alice, which is all the protocol was hoping to achieve. It was ... 3 A zero-knowledge proof is a protocol by which the Prover demonstrate to the Verifier that he knows the solution to a given problem, without giving to the Verifier any additional information about the solution -- that is, no information that the Verifier could not already obtain alone. In the case of the discrete logarithm, the y value is not part of what the ... 3 The premise that people cannot make a memory intensive password hashing function is incorrect. scrypt does approximately what is described in the question. Of course you still want to limit the amount of memory, especially if many of these hashes are to be calculated in parallel. Furthermore, you could have a look at the password hashing competition where ... 3 The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course ... 2 It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ... 2 It is not entirely clear what your exact security requirements are and for which purpose you require this construction. I assume that the tags can not be manipulated by an adversary, e.g., are signed, and that users do not try to change their choice of$x_i$after having a tag. Anyways, I give it a shot (although I may be wrong due to some information I do ... 2 Well, hope that it's not late for this answer. Because it was yesterday that I encountered this problem and I'm new to this wonderful website. According to your description, and as far as I know, this protocol meets your demands very well. First, it works with RSA as you have mentioned in the second paragraph. The original version of this protocol is ... 2 Yes, the same keypairs can be used to derive shared secrets between multiple pairs of parties. If knowing the shared secret between Alice and Bob would help Eve find out the shared secret between Alice and Carol, Eve could just create her own random private key and calculate a "shared" secret between that key and Alice's public key to get the same ... 2 Well, as it says in your link the problem is authentication. So somehow Alice and Bob must set up an authenticated channel. One way of implementing such a channel is by Alice and Bob holding each others public verification key for a signature scheme. A CA would probably not hold a secret key for Alice and Bob. However, using a CA to get an authentic copy ... 2 The algorithm produces a password based on the value of the time that is input as an argument. That value does not have to be the current time. For the purposes for which TOTPs are generally used, there is no value in producing the password for a time other than the current time step - it won't be recognized by the validator. 2 The problem with the HMAC-based solution you drew up is if the shared secret$s$has low entropy; for example, it's actually a password that could conceivably be in a dictionary. In this case, someone could listen to the exchange$r_1, \operatorname{HMAC}(C \mathbin\| r_1, s)$, and go through his dictionary of possible values of$s\$, and see if any one of ...