- cypherpunks - lists.cpunks.org

AirChat radio, and cryptolaw
by grarpamp 24 Apr '14

24 Apr '14

https://github.com/lulzlabs/AirChat/ http://www.computerworld.com.au/article/543477/should_australians_prepare_r…

1 0

regulation on cybersecurity
by dan＠geer.org 23 Apr '14

23 Apr '14

The machinery is spinning up. And the Cobbler's Children Have No Shoes .... http://www.lawfareblog.com/2014/04/and-the-cobblers-children-have-no-shoes/ For those who prefer plaintext, lynx --dump yields the following And the Cobbler's Children Have No Shoes .... By [32]Paul Rosenzweig Monday, April 21, 2014 at 7:00 AM For quite some time, it has been apparent that the announcement of the [33]NIST Cybersecurity Framework would be a seminal event. Though couched as a voluntary program, many expected that [34]the Framework would become the de facto ground for liability. After all, if the National Institute for Standards and Technology has determined a baseline framework for optimal security in the cyber domain, [35]what could be more negligent than failing to meet that minimum standard? Unsurprisingly, the penny has begun to drop. Not, as one might have expected, in private sector tort suits, but in public sector regulatory action. Last week, the Securities and Exchange Commission[36] announced its intention to conduct an examination of the cybersecurity of 50 broker-dealers and investment advisers subject to its jurisdiction. The [37]questionnaire derives much of its content from the NIST Framework--so now the Framework will be the likely potential ground for regulatory action. How ironic then, that in the same week, [38]the GAO issued a report critical of the SEC for its own [39]lack of adequate cybersecurity and oversight. Perhaps the cobbler's children don't have any shoes .... 32. http://www.lawfareblog.com/author/paul/ 33. http://www.lawfareblog.com/2014/02/nist-cybersecurity-framework-issued/ 34. http://safegov.org/2013/11/1/the-nist-cybersecurity-framework-and-incentives 35. http://www.newrepublic.com/article/115187/cybersecurity-liability-court-cas… 36. http://www.digitalcrazytown.com/2014/04/sec-issues-nist-inspired-cybersecur… 37. http://www.sec.gov/ocie/announcement/Cybersecurity+Risk+Alert++%2526+Append… 38. http://www.gao.gov/products/GAO-14-419 39. http://online.wsj.com/news/articles/SB1000142405270230462630457950810040745…

3 2

Fine grain Cross-VM Attacks on Xen and VMware (AES)
by Griffin Boyce 23 Apr '14

23 Apr '14

'AES in a number popular cryptographic libraries including OpenSSL, PolarSSL and Libgcrypt are vulnerable to Bernstein’s correlation attack when run in Xen and VMware virtual machines, the most popular VMs used by cloud service providers.' Abstract: http://eprint.iacr.org/2014/248 Paper: http://eprint.iacr.org/2014/248.pdf So in a nutshell, if you want to steal a website's private keys, you can get an account on their hosting provider and at least have a shot at getting on the same physical server ;-) ~Griffin

2 1

Novena needs crowdfunding help
by Blibbet 22 Apr '14

22 Apr '14

They're 70% there, Bunnie needs help with rest. http://www.bunniestudios.com/blog/?p=3750 http://www.crowdsupply.com/kosagi/novena-open-laptop "$178,790 raised of $250,000 goal"

1 0

Re: [liberationtech] [p2p-hackers] Programming language for anonymity network
by Hannes Mehnert 22 Apr '14

22 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 04/22/2014 21:15, Christof Leng wrote: > I was very happy with Standard ML (non-object-oriented > 'predecessor' of OCAML) for writing complex P2P systems and even > user-land transport protocols. Agreed. I use the Caml part of OCaml. :) > Functional programming and static typing helps to discover subtle > bugs that go unnoticed in imperative languages (and I'm not talking > about something as ridiculous as buffer overruns). > > Unfortunately, Stevens requirement of familiarity still speaks > against functional programming languages, even for something as > popular (and watered-down) as Scala. It's very hard to find code > contributors who know the language or are willing to learn it. But if you have a chance to start from scratch, you should look at possible solutions and use a viable one. Especially the readability and maintainability of a programming language should be considered. Otherwise you end up with a piece of code which is not maintainable once the PhDs have graduated. You have to pay the technical debt at some point. And I'm not sure how to hand over a research project to 'the open source community'... Are there best practices/guidelines availble? I think the OCaml community is rather larger compared to other functional programming languages, and it is very helpful. Both the real world ocaml book, available online https://realworldocaml.org/, and their package management system OPAM, are awesome contributions over the last years to easily start with OCaml and to get more people involved. Cheers, Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBCQAGBQJTVstHAAoJELyJZYjffCjuUqcQAKFUvtAfbLu2yU3EEkR5Mjsv N9f19Ao0tIvmU6PmQAEfrdXNhs1e19xFSseaLPEQibxWBbYXTzx+J0es+/H6a116 CcrZ8N51kM/aOydnRTk2NmoP1BYh9X+S3bQRLPu/lYipgYVyuV7ohzZMqmrguARu 15uWjqmvaDahYZhuu4tnfksggveL59pF/08UA5xd8wZ3I+XMiXB7JviN3Mii2rbk 8BjWFFXW66xQGSxg+nsIp+rGiX6r12gCNZZHJHSoQGcmbalGPVF+o2r7+j+D2ZcC n/tXVVgIy2TO+7mxp+ueX+OK5p+YDqOzFTPDKQhARVP+EjEqZXPRKY4YkgMno8ug 7CT4yCuV84gdrNfudOFKTOx4G0k/4OSZzPVn/g1i9vmqAUU8z6UUBr9tjSR1jZq6 iZqDBGkz34550DlPhxE3mwdFh/woBv2ExgrOvM3iSX/dtKBa7p/fCGNHX17dEIgW 0d1DKQatRjuIGIdAjowy8CuJ4rPceoqoObPutLYVw+PeMfSencjDmf9bmXgFI3jB WU6Jo+akCd/BlvABnV2qLnJXqbo3ixM0B7WbI+c5EyQaPapS5J4Im+b66EE9o57Y Ab5Vf7h0GLVovA+VFXbnNCjoiawQo8rKU276Lwid7i8ZByQhm7iX/obMPTQchyKU z5MCXzwWyXnFRt8MbI+G =N6Jn -----END PGP SIGNATURE-----

1 0

Programming language for anonymity network
by Stevens Le Blond 22 Apr '14

22 Apr '14

Hello, We are a team of researchers working on the design and implementation of a traffic-analysis resistant anonymity network and we would like to request your opinion regarding the choice of a programming language / environment. Here are the criteria: 1) Familiarity: The language should be familiar or easy to learn for most potential contributors, as we hope to build a diverse community that builds on and contributes to the code. 2) Maturity: The language implementation, tool chain and libraries should be mature enough to support a production system. 3) Language security: The language should minimize the risk of security relevant bugs like buffer overflows. 4) Security of runtime / tool chain: It should be hard to inconspicuously backdoor the tool chain and, if applicable, runtime environments. To give two concrete examples: Using the C language + deterministic builds is an attractive option with respect to 1), 2) and 4), but doesn’t provide much regarding 3). Java does better with respect to 3), however, it trades some of 3) and 4) as compared to C. Specifically, we are concerned that large runtimes may be difficult to audit. A similar argument may apply to other interpreted languages. Given these criteria, what language would you choose and for what reasons? We would also appreciate feedback regarding our criteria. All the best, David, Nick, Peter, Stevens, and William

6 6

HW backdoors
by grarpamp 22 Apr '14

22 Apr '14

In your routers, in your cpu's, in your firmwares, in your shorts... magic packets are everywhere. http://www.synacktiv.com/ressources/TCP32764_backdoor_again.pdf

1 0

Re: [Cryptography] Inevitable Security Critiques, Promises and Lemons
by Robert Hettinga 20 Apr '14

20 Apr '14

On Apr 19, 2014, at 10:07 AM, John Young <jya(a)pipeline.com> wrote: > Still hopeful Hettinga will plug these insider breaches of why marketing > lemonade is so lucratively persuasive to those who know better. And who > do not disclose here. I’ll endeavour to persevere… Cheers, RAH

1 0

Inevitable Security Critiques, Promises and Lemons
by John Young 19 Apr '14

19 Apr '14

Gratifying to see a few of those here featured in NY Times today discussing inevitable failures and contradictions in security: http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contra… To be read with Schneier's 2007 account of inevitable security lemons (resurrected by Coderman): https://www.schneier.com/blog/archives/2007/04/a_security_mark.html Our security consumer advice based on frank, honest and distrustful discussions here for nearly 18 years: "Unreliable SSL has been uninstalled. All security and privacy policies are unreliable. Protect yourself against security and privacy promise." Still hopeful Hettinga will plug these insider breaches of why marketing lemonade is so lucratively persuasive to those who know better. And who do not disclose here.

1 0

Lavabit
by dan＠geer.org 18 Apr '14

18 Apr '14

http://www.techweekeurope.co.uk/news/lavabit-snowden-appeal-lost-144112 Lavabit Loses Contempt Of Court Appeal Failure to hand over encryption keys could land Lavabit founder Levison with hefty fines On April 17, 2014 by Thomas Brewster Lavabit, the email service once used by whistleblower Edward Snowden, has lost an appeal against a contempt of court ruling that he delayed the US Government's attempts to gather information by refusing to hand over encryption keys. the email service, which has since closed, was eventually forced to comply anyway. The US government asked for SSL keys to look at the metadata (dates and other details of communications) for a specific Lavabit user, believed to be Snowden, The service's founder Ladar Levison at first refused, and when forced to comply, provided the keys printed in a tiny typeface. The court ruled that Lavabit had not followed correct procedures in its initial hearings, and had not raised a specific challenge to the district court's authority under the so-called "pen/trap statute". Levinson could now be fined for contempt. "Levison's statement to the district court simply reflected his personal angst over complying with the pen/trap order, not his present appellate argument that questions whether the district court possessed the authority to act at all," read a statement from the fourth US circuit court of appeals Judge G Steven Agee. "Arguments raised in a trial court must be specific and in line with those raised on appeal." The case stems back to June last year, when the US government sought to acquire private keys for SSL encrypted traffic of a specific Lavabit user, thought to be Snowden. Officials sought to put a tap on the communications of that target to collect metadata. Levison, when approached by FBI officials, refused to hand over the keys, which eventually led to the contempt of court charge. According to the court filing denying his appeal, Levison suggested he could provide the content the government was after, rather than using their interception tools. The government decline the offer, saying it needed real-time acquisition of the target's data. A device to intercept traffic was installed as part of the pen/trap order, but could not gather usable information as the encryption keys had not been provided. Officials did eventually get the keys in August 2013, however. "The government sought penalties of $5,000 a day until Lavabit provided the encryption keys to the government. The district court granted the motion for sanctions that day. Two days later, Levison provided the keys to the government. By that time, six weeks of data regarding the target had been lost," the court ruling read. Levison could now be fined thousands of dollars.

2 1