# Tag Info

13

This is an active area of research. There have been attempts at creating usable security tools and lots of user studies of existing tools (typically with critical results). A good anthology for work in this area (a few years old now) is Security and Usability edited by Lorrie Cranor and Simson Garfinkel. There is also a workshop every year called Symposium ...

13

A few observations: RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$ Remember that a (Key, IV) pair must not be reused, ever. A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather ...

10

There's an obvious solution using DH: Alice has a private key $a$ and a public key $g^a$; Bob has a private key $b$ and a public key $g^b$. When Bob sends a message, he computes the shared secret value $(g^a)^b$, converts that into a MAC key (possibly using a nonce to prevent key reuse), computes the MAC of the message, and sends the message and the MAC ...

9

Cryptography is being a lot of places already and people might just know about it. For example, whenever you access an HTTPS page, that's cryptography protecting you. For desktop applications, many people use the Truecrypt application to protect their files. You also see a similar application in Windows BitLocker. As for why more people aren't using ...

9

No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so. RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...

8

The main weakness in cryptography is that people are involved. I'm also wondering why the allegedly secure websites (financial/healthcare) that I use, still use password access and still have "security questions" in case I forget my password, where the security questions aren't very secure. There are more secure schemes, however they cost money. ...

8

You could encrypt them using some key derived from the user's password (to your site). Of course, this assumes that you get your user's passwords in plain text (or in any form which is always the same) - thus you need to have an encrypted connection to your user. Do not allow any non-SSL login. You can use some key derivation function like PBKDF or bcrypt ...

8

No, you are not leaking any information except how to MAC those specific values with the specific key you are using. Using a short message is exactly as secure as using a long message. For the following, remember the definition HMAC (K,m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)). There are two hashes here, an outer hash and an inner hash nested inside the ...

7

If your password database will never be compromised, you can store plaintext passwords and nobody will be bothered. The only thing about plaintext passwords is that they can be accidentally remembered by admins who see them - a simple base64 will fix that. Equivalently, MD5 or SHA1, with salt or without, is just as fine. If your password database is ...

6

For Diffie-Hellman, adequate security is achieved provided that: we work modulo a prime $p$ big enough to resist discrete logarithm (1536 bits are sufficient); the order of the subgroup generated by $g$ is a multiple of a big-enough prime integer $q$ ($q$ should have length $2n$ bits to achieve $2^n$ security); the private exponents are randomly chosen in ...

6

Disclaimer: I am writing this based only on what you write and my own guesswork. Last I saw something about "encrypted tokens", it was about server load. When an app uses such a token, the token must be verified against what can be described as a big database of all existing valid tokens. Possibly, some people could have begun to try "random tokens" just in ...

6

I'm considering switching to ECDSA, would this require less space with the same level of encryption? The answer to that question is yes, both ECDSA signatures and public keys are much smaller than RSA signatures and public keys of similar security levels. If you compare a 192-bit ECDSA curve compared to a 1k RSA key (which are roughly the same security ...

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

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

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

"Is to be encrypted" is not a ultimate goal. You do not encrypt data for the sake of it; you encrypt data as a way to ensure a given security property, e.g. transmitting some data between two machines, without compromising the data confidentiality with regards to attackers who may spy on the transmission line (or even alter data in transit). If: your ...

5

The distinction between real and fake salt is arbitrary. I suppose that your method would be called "fake salt" by those who make the distinction (concatenation versus "separate input parameter to the algorithm), but there is not really a difference in practice, as long as the hash algorithm is secure. A bit more secure (in the sence of "provenly secure") ...

5

This question comes up often enough in the context of cryptography that it probably is relevant in a practical sense. I suspect we'll hear even more about it if homomorphic encryption raises interest in "computation in an adversarial setting". It's not just theoretically unsolvable. A great many software development organizations have tried to keep data ...

5

Short version: SPKI links not only names, but authorizations to keys. Also, it uses a better syntax (S-expressions) than X.509 certificates. Long version: What problem does it solve? Both the traditional CA-based public-key infrastructure (PKI) and PGP's web of trust (and other similar systems) do mainly one thing: Linking names to public keys. The ...

5

"Authentic" is defined with regards to an identity. A message from Bob is authentic only insofar as Bob is distinct from Charlie. There must be something which, from the outside, makes Bob and Charlie two different entities. In a computerized world with networks, Alice can "see" other people only through the data they send. Moreover, everybody can buy a ...

5

First, convert the string which is to be encrypted into a sequence of bytes. UTF-8 is easy enough; you may reduce the size a bit, depending on what you know on the input strings (e.g. if the strings are domain names, they are ASCII-compatible, so you need only 7 bits per character -- actually a bit less). For the rest of this post, we need to assume that the ...

5

If the CA issued something with a CSR as the dominant part of the To-Be-Signed field, it wouldn't be a X.509 certificate and hardly any existing software would know what to do with it. I guess the original CSR could be added as an extension, though. Therefore, I suppose you are really asking why the X.509 certificate format wasn't originally specified to ...

5

What you're suggesting is likely good enough, and very likely far more secure than just about any other lock on your house. If the only hash function you can find is MD5, go with it, but make sure to HMAC with the passphrase as the key. Again, it's not going to be the weak point of your security. I'm sure I could pick the lock on your front door faster than ...

5

What you describe looks secure to me, but excessively complicated. The following simpler procedure should suffice: When a password reset token is requested: Generate a secure random token and save it (or a cryptographic hash of it) in the database, along with a timestamp. Overwrite the previous token, if any. Send the token to the user by e-mail ...

5

The standard answer in the research literature is to use information-theoretically secure message authentication codes, typically universal hashing (aka Carter-Wegman authenticators). Of course, you could use computationally-secure message authentication codes, like CMAC or HMAC, if you wanted, though that would partly defeat one of the reasons for using ...

5

The idea that cryptography alone can provide non-repudiation is a myth. I realize it is one that is taught in many crypto textbooks -- but the textbooks are wrong. See, e.g., my answer here and here. I could suggest some constructions (e.g., sign the message, append the signature to the message, then encrypt it using an authenticated encryption mode of ...

5

To get non-repudiation, you must have a "proof" which can be used against the signer himself. Symmetric cryptography, by itself, will not help you there, because a cryptographic proof can only come from some "secret" which is under exclusive control of the signer, and the symmetric model assumes that there is a shared secret between two entities. The concept ...

5

The short answer is: They prepend bits in that way because the scheme is not secure without them. While they might not explain it in English, their proof makes it clear where they use it. Let us construct an attack against the scheme that does not prepend a bit to the blocks. The same idea will work against a version of the scheme that prepends the same ...

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