![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com Date: Sat, 07 Sep 2013 11:36:13 -0700 From: Ray Dillinger <bear@sonic.net> To: cryptography@metzdowd.com In-Reply-To: <00E0407E-0BB6-491B-8DA1-34DFDDBA757F@lrw.com> Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com On 09/06/2013 01:25 PM, Jerry Leichter wrote: > A response he wrote as part of a discussion at http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html: > > Q: "Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions?" > > A: (Schneier) Yes, I believe so. > -- Jerry > Here is another interesting comment, on the same discussion. https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 Schneier states of discrete logs over ECC: "I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry." Is he referring to the "standard" set of ECC curves in use? Is it possible to select ECC curves specifically so that there's a backdoor in cryptography based on those curves? I know that hardly anybody using ECC bothers to find their own curve; they tend to use the standard ones because finding their own involves counting all the integral points and would be sort of compute expensive, in addition to being involved and possibly error prone if there's a flaw in the implementation. But are the standard ECC curves really secure? Schneier sounds like he's got some innovative math in his next paper if he thinks he can show that they aren't. Bear _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
home | help | back | first | fref | pref | prev | next | nref | lref | last | post |