# 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 GQ identification scheme is essentially a zero-knowledge proof of a value$x$such that$x^\mu \equiv J \pmod N$where$N$is an RSA modulus and$(\mu,N)$are system parameters and$J$is known to the verifier and$x$only known to the prover. Now your question is not directly concerned with the aforementioned proof where a user shows the possession of ... 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 ... 6 A is acting as a square-root oracle in that protocol. We can use that oracle to factor$n$and break the scheme. Suppose you are an attacker that wants to impersonate A. You: Pick a random$m$; Send$m^2$to A; Compute$p = \gcd(m_1 - m, n)$, thus factoring$n$. This works with probability$1/2$for each attempt. 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 The protocol's description includes "Alice then encrypts$R_B$with her private key". This has no standard meaning. Comments have clarified it is used an "RSA encryption scheme with proper padding" and I am taking as granted that encryption of$R_B$using the private key half of$K_A$, denoted$K_A^-(R_B)$, is obtained by padding$R_B$as in encryption, then ... 5 The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side. ... 5 For P2P authentication, you can go for web of trust concept. Simply this means, if someone is trusted by people you can trust, you can also trust that unknown person. In OpenPGP, a certificate can be signed by other users who trust the association of that public key with the person or entity listed in the certificate. So trust relationships can be ... 5 Authentication can either mean entity authentication or data authentication. Data authentication is a means to demonstrate that some specific data originates from a specific source and has not been modified during transmission and/or upon storage. It can be achieved by the use of digital signatures in a public key, i.e., asymmetric, setting or message ... 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 ... 4 Google (and other companies) have decided to enable one-time passwords for their 2-factor authentication as a step to improve password security. Here is the webpage that explains what Google is doing in more detail (including source code): https://code.google.com/p/google-authenticator/ In a nutshell, they implement two IETF RFCs, namely RFC 6238 and RFC ... 4 That was a bad edit to Wikipedia. The phrase "Carry-forward verification" is not a standard, well-known term in the cryptographic literature. It should not have been included in Wikipedia without a reference to something more specific. But oh well, no one is perfect, sometimes these things happen. Your request for an elaborate survey of MITM defence is ... 4 You may be interested in something like the Cryptographically Generated Address (CGA) from RFC 3972. CGA is used in Secure Neighbor Discovery Protocol (SEND) of RFC 3971 to bind a public key to an IPv6 address. The basic idea of CGA is to generate part of the IPv6 address by computing a cryptographic hash over the public key. The corresponding private key ... 4 Because$r$is not guaranteed to be a Quadratic Residue, so for random$r$there wouldn't be$m_1$such that$r \equiv m_1^2(\mod n)$, therefore authentication will be impossible in this case. 4 No. Cryptography alone cannot solve this problem. Solving this problem requires a combination of technical (e.g., cryptography, systems security) and non-technical (e.g., legal, regulatory, contractual) solutions. Even the technical part is not solely a cryptography question; it as much about systems security. 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 The Wikipedia article points out a good reason for using a random challenge value: preventing replay attacks. If the hash was always the same (as the hash of the symmetric key would be), then having listened in on one challenge-response cycle, a malicious listener could pass further handshake tests. 3 Since you do not describe why TLS Handshake and IKE are appropriate in your situation, and as long as you don't describe your situation, it's hard to really help you. Also, you haven't stated if it's only IKE that's not appropriate, or if that also includes IKEv2 (which improved the IKE protocol). Therefore, I'll simply assume you meant both. As an ... 3 I think the solution to your problem is a digital signature as CodesInChaos pointed out. Here is how it would work: When a user registers with your server they are given a token which will consist of (at a minimum) the user's id. The server also uses its private key to digitally sign the token (or more likely a hash of the token). Now, say user1 and user2 ... 3 It is important to consider the model in which security is proved. In this case, the attack proceeds in two phases: first a phase where the adversary as a verifier interacts with the honest prover, then a phase where the adversary as a prover interacts with an honest verifier. The adversary wins if the honest prover accepts. The paper proves, under ... 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 No, since finding$a$allows offline checking of passwords.$\:$No, although I can't back this part up. 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 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 compatibility, if not security.) The Skein one is defined in section 4.10 of the paper. It uses ... 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 ...