- cypherpunks - lists.cpunks.org

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

gpg/pgp cli vs 15 years later, why can Johnny still not encrypt?
by Anonymous Remailer (austria) 16 Jan '14

16 Jan '14

To be fair.. maybe it helps to examine the software environment extant at the time pgp was developed.. ie macos was the gui($$$$), AUX had just been abandoned by apple. of the day... and dos 3.0 , unix releases were SCO Microport and Interactive/ all based on Att 5.3.2 sources except for microport which was SVR4, Linux did NOT exist nor did crypto libraries bsd/386 was an unforfilled promise and almost no private individual could afford a sun pizza box to run bsd and xenix was $$$$.. same for qnx(and non standard to boot). . Almost EVERYTHING was command line dos windows 3.0 was just starting to become available pgp 1.0 cli structure was loosely based on CryptMaster(an earlier paid product). ie pgp 1.0 was posted/published from a tandon 60 laptop(i386) running a dos command line version of uucp. and additionally fido and sdn clients on the morning of june 5, 1991 from Santa Cruz,Ca.(this after weeks of prediscussion on the WELL...) then additional copys were posted from random upload points all over silicon valley for the next 96 hours.(yes the van/payphone part of the tale is true also, although the payhones wiring was generally directly accessed using a testset to allow connection of a trailblazer modem(preferred for 19.2kb uploads via uucp to usenet.) pgp 2.0 continues on from there and currently gnupg is the cli choice of script and integration...(albeit with several flaws security and cryptowise.) pgp/gpg never was designed for ANYthing but CLI/script/filter/inline usage in the freeware opensource versions and typically people are incompetent at using CLI by far and large(even so called CS students)... On 1/15/14 4:52 PM, coderman wrote:> ---------- Forwarded message ---------- > From: Steve Weis <steveweis(a)gmail.com> > Date: Wed, Jan 15, 2014 at 10:37 AM > > > As one anecdote, when I TAed the MIT Network and Computer security > course, we assigned "Why Johnny Can't Encrypt" as the first reading. > We asked the students to send us a PGP encrypted & signed message and > tell us how long it took. > > If I recall correctly, it took an average of 30 minutes for > non-existing users to figure out how to use PGP. Think about that. > These were graduate & upperclass undergraduate computer science > students enrolled in a network security course. Everyone had accounts > on the same university system and were mostly using standalone email > clients. > > Best of all, someone decided it would be funny to generate a fake key > for me and post it to pgp.mit.edu. Several students fell for the > trick, didn't verify the key, and encrypted their homework with the > wrong key. It was a great way to drive home the lesson, but we asked > the jokers to kindly revoke their key, which they did. > > Long story short, PGP was still hard to figure out for an experienced > cohort of users, who didn't have the issues of webmail and > proliferation of mobile platforms we have today. I don't think > anything has improved to make it viable for a wider audience. > > > On Wed, Jan 15, 2014 at 2:23 AM, Anders Thoresson <anders(a)thoresson.net> wrote: >> Hi all! >> >> When doing research on email encryption and why it's still not widely used, I've read Alma Whittens "Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0" [1] from '99. I wonder if anyone knows of similar but more recent usability studies on encryption software? >> >> Comparing the findings made by Whittens and compare them to the software available today, not much seems to have happened. But does the conclusion still holds, that a lack of mass-adoption of email encryption is due to problematic UX – or are there other reasons that today are seen as more important? >> >> [1] – https://www.usenix.org/legacy/events/sec99/full_papers/whitten/whitten.ps >> ... >

2 1

Fwd: [liberationtech] 15 years later, why can Johnny still not encrypt?
by coderman 16 Jan '14

16 Jan '14

---------- Forwarded message ---------- From: Steve Weis <steveweis(a)gmail.com> Date: Wed, Jan 15, 2014 at 10:37 AM As one anecdote, when I TAed the MIT Network and Computer security course, we assigned "Why Johnny Can't Encrypt" as the first reading. We asked the students to send us a PGP encrypted & signed message and tell us how long it took. If I recall correctly, it took an average of 30 minutes for non-existing users to figure out how to use PGP. Think about that. These were graduate & upperclass undergraduate computer science students enrolled in a network security course. Everyone had accounts on the same university system and were mostly using standalone email clients. Best of all, someone decided it would be funny to generate a fake key for me and post it to pgp.mit.edu. Several students fell for the trick, didn't verify the key, and encrypted their homework with the wrong key. It was a great way to drive home the lesson, but we asked the jokers to kindly revoke their key, which they did. Long story short, PGP was still hard to figure out for an experienced cohort of users, who didn't have the issues of webmail and proliferation of mobile platforms we have today. I don't think anything has improved to make it viable for a wider audience. On Wed, Jan 15, 2014 at 2:23 AM, Anders Thoresson <anders(a)thoresson.net> wrote: > Hi all! > > When doing research on email encryption and why it's still not widely used, I've read Alma Whittens "Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0" [1] from '99. I wonder if anyone knows of similar but more recent usability studies on encryption software? > > Comparing the findings made by Whittens and compare them to the software available today, not much seems to have happened. But does the conclusion still holds, that a lack of mass-adoption of email encryption is due to problematic UX – or are there other reasons that today are seen as more important? > > [1] – https://www.usenix.org/legacy/events/sec99/full_papers/whitten/whitten.ps >...

1 0