# Tag Info

0

You mention OpenSSH format, so may I assume you can use OpenSSH as part of your solution? If so, how about just using RSA key pairs with an authorized_key file? Example The server only ever has a public key for each user stored on it (nothing to lose to a server compromise) and the client just does RSA authentication (no passwords ever sent - client keeps ...

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

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

0

Both reasons are basically the same. The issue here is the following: Often you only want to compress for transportation (e.g. for sending an email) and decompress for storage (e.g. when storing the email in you local email client) to more efficiently offer features like text search. Because the compression algorithm is non-deterministic you would have to ...

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

0

First, there is a non-security argument in favor of option 2.: if you can cache the AES key across key exchanges, you can save time in key setup. Whether that's relevant I'll leave for you to decide. CTR fails when the same key-input pair is used twice. Let's first assume the nonces $N_a$ and $N_b$ are always unique, and that key derivation and mixing is ...

Top 50 recent answers are included