Tag Info

6

From the court decision, we find out that the researchers didn't in fact reverse engineer the key transponders themselves, but a piece of software called "Tango Programmer" which is a third party tool (software and hardware) used to make transponders. Tango Programmer is readily available, but it appears that it needs to be bought alongside a physical ...

6

If this is simply the AES permutation on a single block, it's hard to find such a pair. If it's AES-ECB with multiple blocks, you can pick each block from either (x1,y1) or (x2,y2), producing a new message that contains parts from each of them. With other modes it depends on that mode, but with many modes there will be a similar mixing attack as for ECB.

6

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol. Among positive things there are to say about CRAM-MD5: The password is not exchanged in ...

6

Sysadmins have switched from one password hash algorithm to another many times. There is a standard process for this switch. The Modular Crypt Format (MCF) is the standard scheme for formatting encrypted passwords, as used by passwd, crypt, etc. (see Why are there $signs in my passwd file? ). MCF uses a single column to store the password hash algorithm ... 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, this looks fine. I assume$A$and$B_i$are trusted parties. The protocol as I understand it looks like this:$A$,$B_1$,…,$B_n$agree on a secret key k.$A$broadcasts messages ($m_1$,MAC($m_1$,$k$)), … , ($m_j$,MAC($m_j$,$k$) which$B_1$,…,$B_n$receive and authenticate. I assume$A$and$B_i$are trusted parties, so no$B_i$will itself ... 5 Digital signatures are used to solve this type of problem. That is, a way for$A$to sign the message for$B$so that$B$is highly confident that$A$signed the message in question. There are lots of signature schemes out there, such as RSA signing, DSA, and others. A MAC is not strictly a digital signature, but has a subset of that functionality and may ... 5 As cybergibbons notes in his answer, the court decision itself is quite interesting reading. In particular, while the details of the "Megamos algorithm" itself are obviously not given in the court decision, the manner in which it is used is described in a surprisingly clear manner in paragraphs 4 and 5: "In detail the way this works is as follows: both ... 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 ... 4 Start by naming the current password type (perhaps 3des-cfb) and storing that value on each record as an additional column in the database. You can now start updating existing records. Enumerate over the values in reasonably sized chunks and hash them securely. bcrypt is a good choice. Store the bcrypted value in the database and change the password type ... 4 An OCB like mode seems impossible with stream-ciphers. It's coupled tightly to the concept of a keyed permutation i.e. a (tweakable) block-cipher. Many authenticated encryption actually combine two distinct primitives. It's just that the specification and API only expose the combination. Essentially these xor a key-stream into the message to encrypt it ... 4 Yes, the scheme is weak, and made weaker by adding the SHA-512 hash of the password. The ciphertext being assumed known, this scheme allows testing if a user password is genuine with little effort: compute the SHA-256 hash of the password to be tested using that as the key, decipher at least the portion of the ciphertext corresponding to the SHA-512 hash ... 4 To answer your question: yes, GMAC does have niche applications where it performs better than either HMAC or CMAC; however it might not make sense for you. First of all, you are correct in that GMAC requires an IV, and bad things happen if a particular IV value is reused; this rather rules out GMAC for some applications, and is a cost even for applications ... 4 Here's a better solution, using a Merkle tree. Suppose the string$S$is$n$letters long. Build a binary tree with$n$leaves, with each leaf corresponding to one letter in the string. Then, each node corresponds to a substring: the$i$th leaf corresponds to the$i$th letter in the string, and an internal node$x$corresponds to the substring obtained by ... 4 “Does anyone know what the Megamos algorithm is?” Yes. According to http://www.bicotech.com/doc/megamos_cr.pdf (PDF) — which provides the best description from my point of view — the Megamos crypto is: MEGAMOS CRYPTO Read-Write High Security Device - Memory organisation Description The MC is a high security Read-Write RFID Transponder. A ... 4 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 ... 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 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 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. ... 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. 3 In addition to the earlier remarks about the missing background of your question please also consider that TLS and IKEv2 are actually not just a single authentication and key exchange protocol but rather a framework that supports many different AKA protocols. Let us use TLS as an example. In TLS you have the concept of ciphersuites and they allow you to ... 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 SIGMA The SIGMA paper does not describe how a "response message" for SIGMA-I would be implemented. If it was implemented as (for example)$B$sending$\:\operatorname{MAC}_{K_m}\hspace{-0.02 in}(\text{"ACK"})\:$to$A$, then that would not actually provide the desired peer awareness property in the case where$\: B = \text{"ACK"} \:$. If || denotes ... 3 Without an out-of-band channel, no. If all Alice has only a public key , she can't tell the difference between Bob's key and Mallory's. Hence Mallory can mount a man in the middle attack. To prevent this you either need a certificate or a a trusted out of band channel though which you conform the key. The channel could be something that is harder to man ... 3 Ask the server for the salt for a specific username. Compute the expensive salted hash on the client, send to server Server performs a cheap unsalted hash(or HMAC) on the hash received from the client and compares with the stored value Note that sending a hashed password doesn't mean you can use an insecure transport. You still need proper transport ... 3 Does it negatively affect security to calculate a hash value of the ciphertext before MAC calculation? Like exchanging step 2. with this: HMAC-SHA256(SHA256(ciphertext)). Technically, yes, but not significantly. In order to attack the scheme you propose, the attacker would have to be able to do at least one of two things: (1) Find an attack on the ... 3 "The problem I face is that all authentication protocols require some kind of shared secret between the devices and the server." Similarly, the problem I face is that$\:1 = 0 \;\;$. Since your post includes "(eg: a digital signature of a random string by the server)", I will assume that the server has a signature key-pair and the devices alrady know ... 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 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 The probability of such a "collision" occurring randomly, with honestly-generated RSA keys, is extremely low. Mathematically justifying that assertion can be tiresome, but the idea is the following: Let$s$be a RSA signature, i.e. an integer of size$k$bits for some$k$(e.g.$k = 2048$). We consider RSA keys$(n,e)$where$n$is the modulus (of size$k\$ ...

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