On 11/14/2016 11:07 AM, [email protected] wrote:
Am 14.11.2016 um 17:35 schrieb Alice Wonder:
On 11/13/2016 06:08 PM, [email protected] wrote:
Am 12.11.2016 um 03:32 schrieb Alice Wonder:
For my equivalent of your Configuration A list, on servers where
sensitive information is transferred to and from the server, I do limit
it to TLS 1.2 and I also only use ECDSA certificates, I haven't yet come
across a user with a client that can do TLS 1.2 that doesn't handle
ECDSA.
Why use (EC)DSA?
DSA based cripto is the first thing that I would deactivate. Many other
guides recommend disableing DSA as well.
Compared to RSA, DSA has some attack vectors that are just unneccessary:
For many operations DSA needs randomness, but in contrast to RSA,
repeated use of the same random data or otherwise compromised random
number generators will not only compromise the security of the specific
operation. If the random numbers are not the best quality, then it is
possible to compromise YOUR PRIVATE KEY.
I use ECDSA because RSA keys are pretty much at their limit, beyond
2048-bit the computation required increases for little gain.
With respect to flawed random generators, solutions like haveged really
help mitigate lack of entropy issues.
haveged is also a solution that looks highly suspicious if you ask me.
Generating random numbers is a very hard and complex matter and the devs
that created generators like /dev/random on linux have put a lot of
thought into it. Having something like haveged "easily" generate large
amounts of randmoness leaves the question why didn't the other
generators use the same technique. It doesn't look trustworthy to me.
But haveged is also a kind of different topic although I would love to
know what the others think about it.
If there is a flaw in the random generator, the private keys generated
for the forward secrecy are already suspect and honestly that is a
bigger concern than the server private key that really is only used for
authentication as DNSSEC helps to prevent many MITM type attacks even
when a private key is compromised (granted that assumes the client
enforces DNSSEC)
PFS though means the actual connection is encrypted with an ephemeral
key, so if the random generator is flawed then the session is vulnerable
even if the server private key is not compromised, no?
There is a key missunderstanding here. Having a broken random number
generator is the worst case scenario. But having a number generator with
a minor flaw, will not affect RSA keys, while it will breakt DSA keys.
But with forward secrecy new keys are generated for each session in
which case even RSA keys could be cracked faster than brute force even
if the long term key wasn't cracked and was generated on a machine with
a proper generator.
_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach
