- cypherpunks - lists.cpunks.org

Re: "Blackphone" said to be "a super-secure nsa-proof"
by coderman 17 Jan '14

17 Jan '14

"super-secure nsa-proof" phone... this shit is hilarious! will it ever get old? :P~ smartphones our Achilles heel: so convenient, so entirely privacy destroying and inherently vulnerable and insecure (as of existing closed baseband systems, proprietary chipsets, poorly keyed, weakly ciphered, horribly authenticated, geo location and side channel leaking sieves we call handsets today that is...) some have suggested the GTA04[0], which i do like, and also liked the original GTA01 back in the day. however, the ideal platform would be wideband SDR on a coreboot mobile with virtualization support (e.g. mobile Qubes OS with MIMO SDR radios and hardware protected key management) one last comment on smart phones and mobile networks: they do offer myriad and many methods to pollute the upstream; indications are this delays rather than defends, but still interesting and enjoyable none the less *grin* 0. OpenMoko GTA04 handsets [avail since 2011] http://wiki.openmoko.org/wiki/GTA04

1 0

Requesting Removal of CARI MACHET/FAKE INDIAN from cypherpunks..
by Anonymous Remailer (austria) 17 Jan '14

17 Jan '14

subject should remove herself for being softheaded to the point of confusing herself Cari Machet is also believed to be working undercover for the NSA

5 5

weasel words: "no evidence that the N.S.A. has implanted its software or used its radio frequency technology inside the United States"
by coderman 17 Jan '14

17 Jan '14

note the misdirection and switcharoo here: """ “N.S.A.'s activities are focused and specifically deployed against — and only against — valid foreign intelligence targets in response to intelligence requirements,” Vanee Vines, an agency spokeswoman, said in a statement. “We do not use foreign intelligence capabilities to steal the trade secrets of foreign companies on behalf of — or give intelligence we collect to — U.S. companies to enhance their international competitiveness or increase their bottom line.” """ these systems have been deployed domestically, albeit under the guise of "valid foreign intelligence targets"... and those a suspiciously close number of hops from same. --- http://cryptome.org/2014/01/nsa-quantum-radio.htm . . . But the program, code-named Quantum, has also been successful in inserting software into Russian military networks and systems used by the Mexican police and drug cartels, trade institutions inside the European Union, and sometime partners against terrorism like Saudi Arabia, India and Pakistan, according to officials and an N.S.A. map that indicates sites of what the agency calls “computer network exploitation.” “What’s new here is the scale and the sophistication of the intelligence agency’s ability to get into computers and networks to which no one has ever had access before,” said James Andrew Lewis, the cybersecurity expert at the Center for Strategic and International Studies in Washington. “Some of these capabilities have been around for a while, but the combination of learning how to penetrate systems to insert software and learning how to do that using radio frequencies has given the U.S. a window it’s never had before.”... There is no evidence that the N.S.A. has implanted its software or used its radio frequency technology inside the United States. While refusing to comment on the scope of the Quantum program, the N.S.A. said its actions were not comparable to China’s. “N.S.A.'s activities are focused and specifically deployed against — and only against — valid foreign intelligence targets in response to intelligence requirements,” Vanee Vines, an agency spokeswoman, said in a statement. “We do not use foreign intelligence capabilities to steal the trade secrets of foreign companies on behalf of — or give intelligence we collect to — U.S. companies to enhance their international competitiveness or increase their bottom line.” Over the past two months, parts of the program have been disclosed in documents from the trove leaked by Edward J. Snowden, the former N.S.A. contractor. A Dutch newspaper published the map of areas where the United States has inserted spy software, sometimes in cooperation with local authorities, often covertly. Der Spiegel, a German newsmagazine, published the N.S.A.'s catalog of hardware products that can secretly transmit and receive digital signals from computers, a program called ANT. The New York Times withheld some of those details, at the request of American intelligence officials, when it reported, in the summer of 2012, on American cyberattacks on Iran. . . .

2 1

Re: [Cfrg] Requesting removal of CFRG co-chair
by John L Grubbs 16 Jan '14

16 Jan '14

4 3

Re: [Cfrg] Requesting removal of CFRG co-chair
by Moritz 16 Jan '14

16 Jan '14

The best thing to do at this stage would be to convince Kevin friendly but firmly that it is in his best interest to step down. This really creates an unhealthy environment, drawing away many others from contributing, something that really should not happen at an open forum like IETF. So, please voice your opinions on the respective IETF lists. On 01/16/2014 09:12 PM, John L Grubbs wrote: > Trevor's request was denied last week. :( > > On Jan 16, 2014 2:04 PM, Cari Machet <carimachet(a)gmail.com> wrote: > > BEAUTIFUL > > Cari Machet > NYC 646-436-7795 > carimachet(a)gmail.com <mailto:carimachet@gmail.com> > AIM carismachet > Syria +963-099 277 3243 > Amman +962 077 636 9407 > Berlin +49 152 11779219 > Twitter: @carimachet <https://twitter.com/carimachet> > > Ruh-roh, this is now necessary: This email is intended only for the > addressee(s) and may contain confidential information. If you are > not the > intended recipient, you are hereby notified that any use of this > information, dissemination, distribution, or copying of this email > without > permission is strictly prohibited. > > > > > On Thu, Jan 16, 2014 at 8:50 PM, Moritz <moritz(a)headstrong.de > <mailto:moritz@headstrong.de>> wrote: > > > https://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html > > > Dear IRTF Chair, IAB, and CFRG: > > I'd like to request the removal of Kevin Igoe from CFRG co-chair. > > The Crypto Forum Research Group is chartered to provide crypto > advice > to IETF Working Groups. As CFRG co-chair for the last 2 years, > Kevin > has shaped CFRG discussion and provided CFRG opinion to WGs. > > Kevin's handling of the "Dragonfly" protocol raises doubts that > he is > performing these duties competently. Additionally, Kevin's > employment > with the National Security Agency raises conflict-of-interest > concerns. > > > Dragonfly Background > ---- > Dragonfly is a "Password-Authenticated Key Exchange" protocol (or > "PAKE"). Dragonfly was proposed to CFRG 2 years ago [PROPOSAL]. > Compared to better-known PAKEs, Dragonfly has no security proof, a > lack of extensive security analysis, nonfunctional complications > added > for IPR reasons, and some security issues [REVIEW]. > > Dragonfly became a hot topic recently when the TLS WG disputed > CFRG's > alleged report that Dragonfly was "satisfactory", as well as > disputing > that this report reflected CFRG consensus [TLS_1]. After extensive > criticism of Dragonfly, the TLS WG ceased work on a Dragonfly > extension [TLS_2]. > > > NSA Background > ---- > The National Security Agency ("NSA") is a U.S. Intelligence Agency > which is believed to devote considerable resources to: > - "Influence policies, standards and specifications for commercial > public key technologies" > - "Shape the worldwide cryptography marketplace to make it more > tractable to advanced cryptanalytic capabilities" [BULLRUN] > > While much is unknown about these activities, the NSA is known > to have > placed a "back door" in a NIST standard for random number generation > [ECDRBG]. A recent report from the President's Review Group > recommends that the NSA: > - "fully support and not undermine efforts to create encryption > standards" > - "not in any way subvert, undermine, weaken, or make vulnerable > generally available commercial software" [PRESIDENTS] > > This suggests the NSA is currently behaving contrary to the > recommendations. > > > Reasons for requesting Kevin's removal > ---- > 1) Kevin has provided the *ONLY* positive feedback for > Dragonfly that > can be found on the CFRG mailing list or meeting minutes. The > contrast between Kevin's enthusiasm and the group's skepticism is > striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based > on. There's no record of Kevin making any effort to understand > Dragonfly's unusual structure, compare it to alternatives, consider > possible use cases, or construct a formal security analysis. > > 2) Twice Kevin suggested a technique for deriving the Dragonfly > password-based element which would make the protocol easy to break > [IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid > timing attacks by adding extra iterations to one of the loops > [IGOE_3, > IGOE_4]. These are surprising mistakes from an experienced > cryptographer. > > 3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG > consensus, which was skeptical of Dragonfly [CFRG_SUMMARY]. > > 4) Kevin's NSA affiliation raises unpleasant but unavoidable > questions regarding these actions. It's entirely possible these are > just mistakes by a novice chair who lacks experience in a particular > sort of protocol and is being pressured by IETF participants to > endorse something. But it's hard to escape an impression of > carelessness and unseriousness in Kevin's work. One wonders whether > the NSA is happy to preside over this sort of sloppy crypto design. > > While that's of course speculation, it remains baffling that an > experienced cryptographer would champion such a shoddy protocol. > The > CFRG chairs have been silent for months, and haven't responded to > attempts to clarify this. > > > Conclusion > ---- > The position of CFRG chair (or co-chair) is a role of crucial > importance to the IETF community. The IETF is in desperate need of > trustworthy crypto guidance from parties who are above suspicion. I > encourage the IAB and IRTF to replace Kevin Igoe with someone > who can > provide this. > > Thanks for considering this request. > > > Trevor > >

2 1

Re: [Cfrg] Requesting removal of CFRG co-chair
by Cari Machet 16 Jan '14

16 Jan '14

link gives a 404 Cari Machet NYC 646-436-7795 carimachet(a)gmail.com AIM carismachet Syria +963-099 277 3243 Amman +962 077 636 9407 Berlin +49 152 11779219 Twitter: @carimachet <https://twitter.com/carimachet> Ruh-roh, this is now necessary: This email is intended only for the addressee(s) and may contain confidential information. If you are not the intended recipient, you are hereby notified that any use of this information, dissemination, distribution, or copying of this email without permission is strictly prohibited. On Thu, Jan 16, 2014 at 9:37 PM, John L Grubbs <john(a)johnlgrubbs.net> wrote: > https://www.ietf.org/mail-archive/web/cfrg/current/msg03736.HTML > > On Jan 16, 2014 2:17 PM, Cari Machet <carimachet(a)gmail.com> wrote: > > > > well that is purely disgusting on what f'ing grounds was it denied? is > there any doc info on that 'transaction' ??? > > > > Cari Machet > > NYC 646-436-7795 > > carimachet(a)gmail.com > > AIM carismachet > > Syria +963-099 277 3243 > > Amman +962 077 636 9407 > > Berlin +49 152 11779219 > > Twitter: @carimachet <https://twitter.com/carimachet> > > > > Ruh-roh, this is now necessary: This email is intended only for the > > addressee(s) and may contain confidential information. If you are not > the > > intended recipient, you are hereby notified that any use of this > > information, dissemination, distribution, or copying of this email > without > > permission is strictly prohibited. > > > > > > > > > > On Thu, Jan 16, 2014 at 9:12 PM, John L Grubbs <john(a)johnlgrubbs.net> > wrote: > >> > >> Trevor's request was denied last week. :( > >> > >> On Jan 16, 2014 2:04 PM, Cari Machet <carimachet(a)gmail.com> wrote: > >>> > >>> BEAUTIFUL > >>> > >>> Cari Machet > >>> NYC 646-436-7795 > >>> carimachet(a)gmail.com > >>> AIM carismachet > >>> Syria +963-099 277 3243 > >>> Amman +962 077 636 9407 > >>> Berlin +49 152 11779219 > >>> Twitter: @carimachet <https://twitter.com/carimachet> > >>> > >>> Ruh-roh, this is now necessary: This email is intended only for the > >>> addressee(s) and may contain confidential information. If you are not > the > >>> intended recipient, you are hereby notified that any use of this > >>> information, dissemination, distribution, or copying of this email > without > >>> permission is strictly prohibited. > >>> > >>> > >>> > >>> > >>> On Thu, Jan 16, 2014 at 8:50 PM, Moritz <moritz(a)headstrong.de> wrote: > >>>> > >>>> > >>>> https://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html > >>>> > >>>> > >>>> Dear IRTF Chair, IAB, and CFRG: > >>>> > >>>> I'd like to request the removal of Kevin Igoe from CFRG co-chair. > >>>> > >>>> The Crypto Forum Research Group is chartered to provide crypto advice > >>>> to IETF Working Groups. As CFRG co-chair for the last 2 years, Kevin > >>>> has shaped CFRG discussion and provided CFRG opinion to WGs. > >>>> > >>>> Kevin's handling of the "Dragonfly" protocol raises doubts that he is > >>>> performing these duties competently. Additionally, Kevin's employment > >>>> with the National Security Agency raises conflict-of-interest > >>>> concerns. > >>>> > >>>> > >>>> Dragonfly Background > >>>> ---- > >>>> Dragonfly is a "Password-Authenticated Key Exchange" protocol (or > >>>> "PAKE"). Dragonfly was proposed to CFRG 2 years ago [PROPOSAL]. > >>>> Compared to better-known PAKEs, Dragonfly has no security proof, a > >>>> lack of extensive security analysis, nonfunctional complications added > >>>> for IPR reasons, and some security issues [REVIEW]. > >>>> > >>>> Dragonfly became a hot topic recently when the TLS WG disputed CFRG's > >>>> alleged report that Dragonfly was "satisfactory", as well as disputing > >>>> that this report reflected CFRG consensus [TLS_1]. After extensive > >>>> criticism of Dragonfly, the TLS WG ceased work on a Dragonfly > >>>> extension [TLS_2]. > >>>> > >>>> > >>>> NSA Background > >>>> ---- > >>>> The National Security Agency ("NSA") is a U.S. Intelligence Agency > >>>> which is believed to devote considerable resources to: > >>>> - "Influence policies, standards and specifications for commercial > >>>> public key technologies" > >>>> - "Shape the worldwide cryptography marketplace to make it more > >>>> tractable to advanced cryptanalytic capabilities" [BULLRUN] > >>>> > >>>> While much is unknown about these activities, the NSA is known to have > >>>> placed a "back door" in a NIST standard for random number generation > >>>> [ECDRBG]. A recent report from the President's Review Group > >>>> recommends that the NSA: > >>>> - "fully support and not undermine efforts to create encryption > standards" > >>>> - "not in any way subvert, undermine, weaken, or make vulnerable > >>>> generally available commercial software" [PRESIDENTS] > >>>> > >>>> This suggests the NSA is currently behaving contrary to the > recommendations. > >>>> > >>>> > >>>> Reasons for requesting Kevin's removal > >>>> ---- > >>>> 1) Kevin has provided the *ONLY* positive feedback for Dragonfly that > >>>> can be found on the CFRG mailing list or meeting minutes. The > >>>> contrast between Kevin's enthusiasm and the group's skepticism is > >>>> striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based > >>>> on. There's no record of Kevin making any effort to understand > >>>> Dragonfly's unusual structure, compare it to alternatives, consider > >>>> possible use cases, or construct a formal security analysis. > >>>> > >>>> 2) Twice Kevin suggested a technique for deriving the Dragonfly > >>>> password-based element which would make the protocol easy to break > >>>> [IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid > >>>> timing attacks by adding extra iterations to one of the loops [IGOE_3, > >>>> IGOE_4]. These are surprising mistakes from an experienced > >>>> cryptographer. > >>>> > >>>> 3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG > >>>> consensus, which was skeptical of Dragonfly [CFRG_SUMMARY]. > >>>> > >>>> 4) Kevin's NSA affiliation raises unpleasant but unavoidable > >>>> questions regarding these actions. It's entirely possible these are > >>>> just mistakes by a novice chair who lacks experience in a particular > >>>> sort of protocol and is being pressured by IETF participants to > >>>> endorse something. But it's hard to escape an impression of > >>>> carelessness and unseriousness in Kevin's work. One wonders whether > >>>> the NSA is happy to preside over this sort of sloppy crypto design. > >>>> > >>>> While that's of course speculation, it remains baffling that an > >>>> experienced cryptographer would champion such a shoddy protocol. The > >>>> CFRG chairs have been silent for months, and haven't responded to > >>>> attempts to clarify this. > >>>> > >>>> > >>>> Conclusion > >>>> ---- > >>>> The position of CFRG chair (or co-chair) is a role of crucial > >>>> importance to the IETF community. The IETF is in desperate need of > >>>> trustworthy crypto guidance from parties who are above suspicion. I > >>>> encourage the IAB and IRTF to replace Kevin Igoe with someone who can > >>>> provide this. > >>>> > >>>> Thanks for considering this request. > >>>> > >>>> > >>>> Trevor > >>> > >>> > > >

1 1

Re: [Cfrg] Requesting removal of CFRG co-chair
by Cari Machet 16 Jan '14

16 Jan '14

well that is purely disgusting on what f'ing grounds was it denied? is there any doc info on that 'transaction' ??? Cari Machet NYC 646-436-7795 carimachet(a)gmail.com AIM carismachet Syria +963-099 277 3243 Amman +962 077 636 9407 Berlin +49 152 11779219 Twitter: @carimachet <https://twitter.com/carimachet> Ruh-roh, this is now necessary: This email is intended only for the addressee(s) and may contain confidential information. If you are not the intended recipient, you are hereby notified that any use of this information, dissemination, distribution, or copying of this email without permission is strictly prohibited. On Thu, Jan 16, 2014 at 9:12 PM, John L Grubbs <john(a)johnlgrubbs.net> wrote: > Trevor's request was denied last week. :( > On Jan 16, 2014 2:04 PM, Cari Machet <carimachet(a)gmail.com> wrote: > > BEAUTIFUL > > Cari Machet > NYC 646-436-7795 > carimachet(a)gmail.com > AIM carismachet > Syria +963-099 277 3243 > Amman +962 077 636 9407 > Berlin +49 152 11779219 > Twitter: @carimachet <https://twitter.com/carimachet> > > Ruh-roh, this is now necessary: This email is intended only for the > addressee(s) and may contain confidential information. If you are not the > intended recipient, you are hereby notified that any use of this > information, dissemination, distribution, or copying of this email without > permission is strictly prohibited. > > > > > On Thu, Jan 16, 2014 at 8:50 PM, Moritz <moritz(a)headstrong.de> wrote: > >> >> https://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html >> >> >> Dear IRTF Chair, IAB, and CFRG: >> >> I'd like to request the removal of Kevin Igoe from CFRG co-chair. >> >> The Crypto Forum Research Group is chartered to provide crypto advice >> to IETF Working Groups. As CFRG co-chair for the last 2 years, Kevin >> has shaped CFRG discussion and provided CFRG opinion to WGs. >> >> Kevin's handling of the "Dragonfly" protocol raises doubts that he is >> performing these duties competently. Additionally, Kevin's employment >> with the National Security Agency raises conflict-of-interest >> concerns. >> >> >> Dragonfly Background >> ---- >> Dragonfly is a "Password-Authenticated Key Exchange" protocol (or >> "PAKE"). Dragonfly was proposed to CFRG 2 years ago [PROPOSAL]. >> Compared to better-known PAKEs, Dragonfly has no security proof, a >> lack of extensive security analysis, nonfunctional complications added >> for IPR reasons, and some security issues [REVIEW]. >> >> Dragonfly became a hot topic recently when the TLS WG disputed CFRG's >> alleged report that Dragonfly was "satisfactory", as well as disputing >> that this report reflected CFRG consensus [TLS_1]. After extensive >> criticism of Dragonfly, the TLS WG ceased work on a Dragonfly >> extension [TLS_2]. >> >> >> NSA Background >> ---- >> The National Security Agency ("NSA") is a U.S. Intelligence Agency >> which is believed to devote considerable resources to: >> - "Influence policies, standards and specifications for commercial >> public key technologies" >> - "Shape the worldwide cryptography marketplace to make it more >> tractable to advanced cryptanalytic capabilities" [BULLRUN] >> >> While much is unknown about these activities, the NSA is known to have >> placed a "back door" in a NIST standard for random number generation >> [ECDRBG]. A recent report from the President's Review Group >> recommends that the NSA: >> - "fully support and not undermine efforts to create encryption >> standards" >> - "not in any way subvert, undermine, weaken, or make vulnerable >> generally available commercial software" [PRESIDENTS] >> >> This suggests the NSA is currently behaving contrary to the >> recommendations. >> >> >> Reasons for requesting Kevin's removal >> ---- >> 1) Kevin has provided the *ONLY* positive feedback for Dragonfly that >> can be found on the CFRG mailing list or meeting minutes. The >> contrast between Kevin's enthusiasm and the group's skepticism is >> striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based >> on. There's no record of Kevin making any effort to understand >> Dragonfly's unusual structure, compare it to alternatives, consider >> possible use cases, or construct a formal security analysis. >> >> 2) Twice Kevin suggested a technique for deriving the Dragonfly >> password-based element which would make the protocol easy to break >> [IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid >> timing attacks by adding extra iterations to one of the loops [IGOE_3, >> IGOE_4]. These are surprising mistakes from an experienced >> cryptographer. >> >> 3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG >> consensus, which was skeptical of Dragonfly [CFRG_SUMMARY]. >> >> 4) Kevin's NSA affiliation raises unpleasant but unavoidable >> questions regarding these actions. It's entirely possible these are >> just mistakes by a novice chair who lacks experience in a particular >> sort of protocol and is being pressured by IETF participants to >> endorse something. But it's hard to escape an impression of >> carelessness and unseriousness in Kevin's work. One wonders whether >> the NSA is happy to preside over this sort of sloppy crypto design. >> >> While that's of course speculation, it remains baffling that an >> experienced cryptographer would champion such a shoddy protocol. The >> CFRG chairs have been silent for months, and haven't responded to >> attempts to clarify this. >> >> >> Conclusion >> ---- >> The position of CFRG chair (or co-chair) is a role of crucial >> importance to the IETF community. The IETF is in desperate need of >> trustworthy crypto guidance from parties who are above suspicion. I >> encourage the IAB and IRTF to replace Kevin Igoe with someone who can >> provide this. >> >> Thanks for considering this request. >> >> >> Trevor >> > >

1 0

Re: [Cfrg] Requesting removal of CFRG co-chair
by John L Grubbs 16 Jan '14

16 Jan '14

1 0

[Cfrg] Requesting removal of CFRG co-chair
by Moritz 16 Jan '14

16 Jan '14

https://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html Dear IRTF Chair, IAB, and CFRG: I'd like to request the removal of Kevin Igoe from CFRG co-chair. The Crypto Forum Research Group is chartered to provide crypto advice to IETF Working Groups. As CFRG co-chair for the last 2 years, Kevin has shaped CFRG discussion and provided CFRG opinion to WGs. Kevin's handling of the "Dragonfly" protocol raises doubts that he is performing these duties competently. Additionally, Kevin's employment with the National Security Agency raises conflict-of-interest concerns. Dragonfly Background ---- Dragonfly is a "Password-Authenticated Key Exchange" protocol (or "PAKE"). Dragonfly was proposed to CFRG 2 years ago [PROPOSAL]. Compared to better-known PAKEs, Dragonfly has no security proof, a lack of extensive security analysis, nonfunctional complications added for IPR reasons, and some security issues [REVIEW]. Dragonfly became a hot topic recently when the TLS WG disputed CFRG's alleged report that Dragonfly was "satisfactory", as well as disputing that this report reflected CFRG consensus [TLS_1]. After extensive criticism of Dragonfly, the TLS WG ceased work on a Dragonfly extension [TLS_2]. NSA Background ---- The National Security Agency ("NSA") is a U.S. Intelligence Agency which is believed to devote considerable resources to: - "Influence policies, standards and specifications for commercial public key technologies" - "Shape the worldwide cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities" [BULLRUN] While much is unknown about these activities, the NSA is known to have placed a "back door" in a NIST standard for random number generation [ECDRBG]. A recent report from the President's Review Group recommends that the NSA: - "fully support and not undermine efforts to create encryption standards" - "not in any way subvert, undermine, weaken, or make vulnerable generally available commercial software" [PRESIDENTS] This suggests the NSA is currently behaving contrary to the recommendations. Reasons for requesting Kevin's removal ---- 1) Kevin has provided the *ONLY* positive feedback for Dragonfly that can be found on the CFRG mailing list or meeting minutes. The contrast between Kevin's enthusiasm and the group's skepticism is striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based on. There's no record of Kevin making any effort to understand Dragonfly's unusual structure, compare it to alternatives, consider possible use cases, or construct a formal security analysis. 2) Twice Kevin suggested a technique for deriving the Dragonfly password-based element which would make the protocol easy to break [IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid timing attacks by adding extra iterations to one of the loops [IGOE_3, IGOE_4]. These are surprising mistakes from an experienced cryptographer. 3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG consensus, which was skeptical of Dragonfly [CFRG_SUMMARY]. 4) Kevin's NSA affiliation raises unpleasant but unavoidable questions regarding these actions. It's entirely possible these are just mistakes by a novice chair who lacks experience in a particular sort of protocol and is being pressured by IETF participants to endorse something. But it's hard to escape an impression of carelessness and unseriousness in Kevin's work. One wonders whether the NSA is happy to preside over this sort of sloppy crypto design. While that's of course speculation, it remains baffling that an experienced cryptographer would champion such a shoddy protocol. The CFRG chairs have been silent for months, and haven't responded to attempts to clarify this. Conclusion ---- The position of CFRG chair (or co-chair) is a role of crucial importance to the IETF community. The IETF is in desperate need of trustworthy crypto guidance from parties who are above suspicion. I encourage the IAB and IRTF to replace Kevin Igoe with someone who can provide this. Thanks for considering this request. Trevor

2 1

pie in sky suites - long lived public key pairs for persistent identity
by coderman 16 Jan '14

16 Jan '14

use case is long term (decade+) identity rather than privacy or session authorization. eternity key signs working keys tuned for speed with limited secret life span (month+). working keys are used for secret exchange and any other temporal purpose. you may use any algorithms desired; what do you pick? Curve3617+NTRU eternity key Curve25519 working keys ChaCha20+Poly1305-AES for sym./mac ? this assumes key agility by signing working keys with all eternity keys, and promoting un-broken suites to working suites as needed. you cannot retro-actively add new suites to eternity keys; these must be selected and generated extremely conservatively. other questions: - would you include another public key crypto system with the above? (if so, why?) - does GGH signature scheme avoid patent mine fields? (like NTRU patents) - is it true that NSA does not use any public key scheme, nor AES, for long term secrets? - are you relieved NSA has only a modest effort aimed at keeping an eye on quantum cryptanalysis efforts in academia and other nations? best regards,

1 1