# Tag Info

3

With a hash function that is vulnerable to length extension attacks, like SHA-256, you can turn any random collision into a collision with that random string concatenated with some (partially) chosen data. In any use case where random initial data does not matter, you could use it to generate two documents which have the same hash value and thus the same ...

2

Yes, it's okay. This is actually mentioned in passing in the SRP 6 design paper. Previous versions used a random $u$ where an attacker who saw (or could predict) it before revealing $A$ could compute $A = g^a v^{-u}$ and use this to effectively cancel out the long term secret. With $u$ derived from a hash, even if the attacker saw $B$, the dependence of $u$ ...

2

I can see some weaknesses in your protocol. For example, it allows any attacker to request the encrypted private key and thus mount an offline dictionary or brute force attack on the password. (An incorrect password doesn't give you a properly formatted OpenSSH key.) Thus this is a good idea: I'd rather use something proven. As mentioned in the ...

1

Your idea seems secure, but it is more complicated than it needs to be. If you only need to know if the "secure information" in the document matches some public information (stored on an insecure computer), it is enough to calculate a preimage resistant hash of the document (e.g. SHA-256). The document needs only to be unguessable, like a 256-bit random ...

1

TL;DR: use (D)TLS. This is exactly the kind of problem it was meant to solve. If possible, use cert pinning too (if you get to deploy the code on both ends of the channel, this should be possible). The general rule is: don't design your own crypto protocol unless both of the following apply. You have done a detailed review of what exists already and ...

1

I have sent this question to the ProVerif mailing list as suggested in the comments. The response I obtained from Bruno Blanchet was as follows. Actually, ProVerif does not say that the code is dead, it just says that it cannot prove that it is not dead. (It says "RESULT not attacker:serverFinished_96[...] cannot be proved.") If it said "RESULT not ...

1

As for the first reason: in the future you probably need the decompressed form of the message. There won't be much you can do with the compressed message. But PGP is application level; you may want to verify that message at any time. Now you may want to verify the signature over that decompressed data without compressing it first. E.g. it's a good use case ...

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