From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] Mark recommended ciphers/algorithms Date: Tue, 15 Dec 2015 21:18:28 +0000 Message-ID: <1450214308.31655.190.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0884999457701782549==" List-Id: --===============0884999457701782549== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2015-12-15 at 16:03 +0100, Larsen wrote: > > > > Furthermore, I think that we the upper bound should be > > > > something > > > > that > > > > the average IPFire box is able to handle. > > > I agree with that. Maybe 3072 bits is a good deal between speed > > > and > > > security, what do you think? > > > > That depends entirely on the hardware. We cannot know what people > > are > > using. That makes it rather complicated to decide. > > Is there a way to present the users a message and let them decide > which > length they want to use? Yes, the user has to decide this at some occasions. > > > > > > There seems to be a problem with the word "recommended". In the > > > patches > > > submitted, I recommended always the most strongest cipher. > > > However, > > > as > > > you said, some of them are simply one step too much. Should then > > > both > > > be > > > recommended? > > > > I am not sure. Can anyone come up with a more fitting expression? > > If we > > mark everything as "recommended" that is strong enough for now > > after > > our consideration, we will have most of them tagged with that word. > > In > > that case it would make more sense to mark the weak stuff as such > > to > > keep readability. Maybe that is the way to go. But does the average > > Joe > > know what is meant by "weak"? > > Joe should know enough that "weak" is normally not what is wanted. > Otherwise he should RTFM ;-) > > You could recommend the strongest cipher that would take an attacker > millions of years to break, but on the other hand force the hardware > to > burn its CPU, while another "not as strong as the recommended one" > cipher > would also take an attacker thousands of years, but not consume that > much > CPU. It is always about the tradeoffs. If we didn't have to do these we wouldn't have AES. We would only use OTP. > Would have to differentiate between "recommended for high performance > > CPU" and "recommended for your small box". So, that doesn't sound > good. That doesn't sound good at all because it is not really the case that there is such a big difference between the throughput of some of the algorithms. The right thing would be to upgrade the hardware and keep the strong security. > > Weak is weak for every kind of hardware. So +1 for "weak". If we have "weak". Should we have "broken", too? For example we have to support MD5. I wouldn't say that MD5 is weak. It is more than that. > > > Lars -Michael --===============0884999457701782549== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSldjSU9sQUFvSkVJQjU4UDl2a0FrSDJ6MFAvMGdFa005aWNjenZ0K2Qyd3NEQkkzcVUK YmdTNVFESTB1VXo1YTg4Q0cwcVdtd3RkWWlqZXQvNVA3YklXWW8reDVqN2RsajB0UUI3b3RKazZ6 TzFkQXV3MgpEUE1lK1BjcFFaZUxYc2Y2cUNjOEFRRHRPOUZIT2ZCbHVIQlQ0K21XcHJFbXN6cy80 Mkk5cTljS0Zna3I0d2I2CkJzNXJ1bGsrVUxmQUhUZ2xXVk5VbUoyc0thQmdNdE9XRDlMREp6MFU2 eEc1V2xlaVp0OVJpUi9QdjU2ZkZQcG8KR09LRTVINkxsL21XaEMrdThCS01KbmJKUmRjeC9WQ1kr ZmdmeDNNMWNHUDdyMHRaU0F2UGpNQmFBRjBEc0NhYwp1c0d0WjlRTUZ3azBodFBMckE4OUU2ZzN5 dm5qNmNPaEVqOGNjekM5aUdrUGZmRGNTK1VlQzF0UWJOUTBXTHhjCkpqVVF1WHdhR2tqalpjQ1pK dHZXSlNKOG1ocTNUcElRYW1YVk5zNVFLUHdsSHF1YW9uUklrRkdYWnU0NjlPQ20KM2UzVndJNS9X ckN2WHpmWXVRc2Q4L1NYVUp1K1RwbXNTMmRMazJnb0UwZEg3UyszWE9TNU1OYkJES1JSdCtFRwpD dExkR3FRZGZpbmNmNUZmSkRNdlFSNjF2L2I5Y0N0M1JCeEVjOUFYbm95QmtwdXo0OHMxKzdwajhl R2F3a0xqClZ1OHBVMzRRVXdoRXJWeVREbkp1N3RZS0JUQXJUOUJsM0dkNzZjNkZ0dWwvSzZUWEpo NnNpaWxGclpTTUd4aVYKTFZPWTh3Yml1UmNGUXZhcHlkK01aUWNaQURkUjZ0ZWNUejNONjlQWmJV ZTIyTXJsRlp2dytqV3NjRnprYndhYwpZZ3cwYkNIb2RtcXBGcTVvVnhXSgo9aUg4agotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============0884999457701782549==--