# Tag Info

9

What happens if the sender is at another point in the sequence? ... the key is pressed while out of range to the car. In a rolling code (code hopping) system, the keyfob transmitter maintains a synchronization counter C, incremented every time a button is pushed. The car receiver stores the most recent validated synchronization counter it has received ...

9

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 ... 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 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. ... 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 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 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. 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 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 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 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 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 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 HMAC nor a KDF is needed here. As long as you always use a constant size key and "tag" (generally called a nonce, as in number-used-once) you can simply use a secure hash function, like SHA-256. My suggestion is to drop keeping track of the tags sent so far - this administration is bound to fail at some point. Instead, generate a 32 byte random number. This ... 3 What you are looking for is how to implement an SSL/TLS layer on top of your TCP connection. Try to use the OpenSSL library, it's the most popular implementation. 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 As Marcin already said, nonces are for replay protection. Imagine an attacker records message 2 and later on manages to comprimise the old key. He could then impersonate$ S $and make$ A$and$ B $reuse the old key by sending the recorded message to$ A $. To prevent this, the nonce is included.$ A \$ remembers previously received nonces and does not ...

3

From RFC 4880 - Open PGP Message Format (emphasis added) OpenPGP implementations SHOULD compress the message after applying the signature but before encryption. As the signature provides authentication, and you specifically ask about authentication, I think that quote from the RFC should answer your question. Compression does not affect ...

3

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 ...

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. ...

Only top voted, non community-wiki answers of a minimum length are eligible