- cypherpunks@lists.ogf.org

Re: [Cryptography] $750k Fine for exporting crypto
by John Young 08 Nov '14

08 Nov '14

The global internal rot of digital technology dependence appears doing quite well by inducing ever greater investment and reliance upon it. Will over-reliance upon secret cryptography be its Achilles heel? Let us hope so. Conumdrum is that wholesale monitoring is the result of ubiquitous digital technology, networks and programs thickly hidden by secret cryptography, thinly protected, if at all, by never quite effective public cryptography, ineffective by law by design, by implementation and by endless excuses to do better next time. The correlation between the rise of the Internet to advance global surveillance and public cryptography to persuade the populace there is hope the surveillance can be countered, is occasionally noted but not by cryptography fetishists who promote the notion it is possible to have a global platform of diverse levels for multiple open and secret uses but still protect at least a few of the levels with encryption. This despite the legacy of cryptography as a deceptive technology through and through and foremost, in particular by misleading about its strengths and weaknesses, its treachery and double-dealing, its cheating and betraying, its false promises and "confessed" failures. No doubt all forms of security share these characteristics, eventual failure is the fundamental outcome of a security system subject to ceaseless attack. Every fortress fails, every weapon is surpassed, every peace treaty is transgressed, every ideology collapses, every nation is overturned; in all cases by excessive conviction that failure will not happen, and when it does, it occurs by the least expected means. After a few attempts to repair the majestic defense and prolong a regime, it finally implodes most often due to internal rot of those unable to give up comfortable convictions that munitions are invulnerable, that supreme command and control is protected against tampering, that oaths and rewards of fealty to the homeland are insurpassable. Except for the planted cheats of anonymizers and encryption. >What we are seeing today is unprecedented in American >history: Wholesale monitoring of entire populations, "just in case" >the information might be "needed" later. Saying "beware, someone >evil like Nixon could use this stuff" *misses the point*: It's bad >*even if never abused*. Its mere *existence* is abuse, no matter >who controls it. If the system were under the control of a saintly >administration consisting of nothing but good actors, and there were >a magic button that would be pressed just before they handed over >the reigns to someone not so saintly that magically erased all the >stored information and destroyed the information-gathering systems >... it would *still* be wrong.

1 0

Fwd: [Announce] GnuPG 2.1.0 "modern" released
by coderman 08 Nov '14

08 Nov '14

---------- Forwarded message ---------- From: Werner Koch <wk(a)gnupg.org> Date: Thu, 06 Nov 2014 10:01:51 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released Hello! The GnuPG Project is pleased to announce the availability of a new release: Version 2.1.0. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG-2.1 ======================= - The file "secring.gpg" is not anymore used to store the secret keys. Merging of secret keys is now supported. - All support for PGP-2 keys has been removed for security reasons. - The standard key generation interface is now much leaner. This will help a new user to quickly generate a suitable key. - Support for Elliptic Curve Cryptography (ECC) is now available. - Commands to create and sign keys from the command line without any extra prompts are now available. - The Pinentry may now show the new passphrase entry and the passphrase confirmation entry in one dialog. - There is no more need to manually start the gpg-agent. It is now started by any part of GnuPG as needed. - Problems with importing keys with the same long key id have been addressed. - The Dirmngr is now part of GnuPG proper and also takes care of accessing keyserver. - Keyserver pools are now handled in a smarter way. - A new format for locally storing the public keys is now used. This considerable speeds up operations on large keyrings. - Revocation certificates are now created by default. - Card support has been updated, new readers and token types are supported. - The format of the key listing has been changed to better identify the properties of a key. - The gpg-agent may now be used on Windows as a Pageant replacement for Putty in the same way it is used for years on Unix as ssh-agent replacement. - Creation of X.509 certificates has been improved. It is now also possible to export them directly in PKCS#8 and PEM format for use on TLS servers. A detailed description of the changes can be found at https://gnupg.org/faq/whats-new-in-2.1.html . Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig This is the GnuPG 2.1 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig This is an experimental installer for Windows including GPA as graphical key manager and GpgEX as an Explorer extension. Please de-install an already installed Gpg4win version before trying this installer. This binary version has not been tested very well, thus it is likely that you will run into problems. The complete source code for the software included in this installer is in the same directory; use the suffix ".tar.xz" instead of ".exe". Although several beta versions have been released over the course of the last years, no extensive public field test has been done. Thus it is likely that bugs will show up. Please check the mailing list archives and the new wiki https://wiki.gnupg.org for latest information on known problems and workaround. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.0.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.0.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.0.tar.bz2 and check that the output matches the first line from the following list: 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com> rsa2048/33BD3F06 2014-10-29 Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org> rsa2048/7EFD60D9 2014-10-19 Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Internationalization ==================== This new branch of GnuPG has support for 4 languages: French, German, Japanese, and Ukrainian. More translations can be expected with the next point releases. Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug <https://gnupg.org/documentation/mailing-lists.html>. We suggest to send bug reports for a new release to this list in favor of filing a bug at <https://bugs.gnupg.org>. For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. A final big Thank You goes to Hal Finney, who too early passed away this year. Hal worked on PGP and helped to make OpenPGP a great standard; it has been a pleasure having worked with him.

5 5

Darknets/science vs. GPA/LEA/Law, and playing dirty pool
by grarpamp 08 Nov '14

08 Nov '14

On Fri, Nov 7, 2014 at 9:29 AM, Öyvind Saether <oyvinds(a)everdot.org> wrote: >> http://www.bbc.com/news/technology-29950946 > > "The BBC understands that the raid represented both a technological > breakthrough - with police using new techniques to track down the > physical location of dark net servers" > > They do have the capability to locate Tor hidden services at this point. > > To those who want to pretend otherwise: The first step to fixing a > problem is to admit that it exists. There is no point in pretending > these .onion sites are secure anymore. The only interesting question > now is: How can this be fixed? > > They could simply look for high amounts of Tor traffic and pull the > plug in IPs whos traffic pattern look like it may be a hidden service > and see if anything goes down. This is a critical weakness of any anonymous system if... the way things are looking worldwide, GPA's seem to be the real deal and they seem to have no problem handing off to the LE side, and laws be damned... well, the old ways are over, it's the Wild West. Filling all the network links with chaff could be a way to protect users (maybe they were just loading the homepage over and over), but they could still bounce all the IP's to look for servers. There may be an oppurtunity for the operators of anonymous services to band together and monitor themselves or each other for bounces simply to confirm if bounce tests are infact happening against all such service participants, high data/connection rate ones, services based on age of identity key, or any other such class they are able to identify. And they'd have to characterize true bounces from network reachability anomalys. This is hard to defend against. Store-and-forward... maybe. Decentralized p2p/blockchain... more likely, at least for market-like things that could be modeled as transaction-listing-like things. Another way to test is for someone to use perfect opsec (wifi, tor, bitcoin, etc), and actually run a number of illegal sites and see what happens. Then consider some sites may be allowed to live even if actionable, or simply won't be taken down if there are no real world links to act on. Tor had one recent whitepaper that claimed to have actually located hidden services (real or test) within a minor budget and timeframe by abusing nothing other than the Tor network itself. Right? Has anyone replicated that work? People need to be analysing these court documents very carefully to see what bits of knowledge can be drawn from them. That's a project in itself and EFF/Tor wiki would be a good home to begin cataloging them all and making notes of such things in each case. It's pretty obvious something is going on besides opsec, especially with the quotes in the news. Question is, what is it? Tests need done, knowledge needs found, capabilities need catalogued, and defenses need developed. Step by step, scientific method. While you're at it, play some dirty pool in return, set up a bounty for leakers. Cash, sex, drugs, whatever. Not everyone is motivated by the same things Ellsberg/Snowden et al are. > Regardless of how it is actually done: It seems perfectly clear that > they are able to identify the servers hosting hidden services. Those > who pretend otherwise at this point are either cointelpro/military/law > enforcement or morons.

1 2

Re: [Cryptography] Third amendment crypto defenses
by grarpamp 07 Nov '14

07 Nov '14

On Fri, Nov 7, 2014 at 4:37 PM, Steve Furlong <demonfighter(a)gmail.com> wrote: > On Fri, Nov 7, 2014 at 2:46 PM, Phillip Hallam-Baker <phill(a)hallambaker.com> > wrote: >> >> I think there is a reasonable interpretation >> which would find that the military should not have anything to do with >> such activities. > > Check the cypherpunks archives from 2001 or 2002. This is not a new idea. http://www.metzdowd.com/mailman/listinfo/cryptography Forwarding context to cpunks... http://scholarship.law.wm.edu/wmborj/vol2/iss1/4 http://www.usatoday.com/story/opinion/2013/07/22/third-amendment-nsa-spying… http://misguidedchildren.com/technology/2014/01/nsa-violating-3rd-amendment…

1 0

Node Operators Web Of Trust
by grarpamp 07 Nov '14

07 Nov '14

Is it not time to establish a node operator web of trust? Look at all the nodes out there with or without 'contact' info, do you really know who runs them? Have you talked with them? What are their motivations? Are they your friends? Do you know where they work, such as you see them every day stocking grocery store, or in some building with a badge on it? Does their story jive? Are they active in the community/spaces we are? Etc. This is huge potential problem. NOWoT participation is optional, it is of course infiltratable, and what it proves may be arguable, but it seems a necessary thing to try as a test of that and to develop a good model. Many operators know each other in person. And the node density per geographic region supports getting out to meet operators even if only for the sole purpose of attesting 'I met this blob of flesh who proved ownership of node[s] x'. That's a big start, even against the sybil agents they'd surely send out to meet you. Many know exactly who the other is in the active community such that they can attest at that level. And so on down the line of different classes of trust that may be developed and asserted over each claimed operator. Assuming a NOWoT that actually says something can be established, is traffic then routable by the user over nodes via trust metrics in addition to the usual metrics and randomness? WoT's are an ancient subject... now what are the possibilities and issues when asserting them over physical nodes, not just over virtual nodes such as an email address found in your pubkey? And what about identities that exist only anonymously yet can prove control over various unique resources? If such WoT's cannot be proven to have non-value, then it seems worth doing. This doesn't just apply to Tor, but to any node based system.

1 0

Re: [tor-relays] [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by grarpamp 07 Nov '14

07 Nov '14

On Thu, Nov 6, 2014 at 2:43 AM, David Serrano <tor(a)dserrano5.es> wrote: > On 2014-11-05 23:58:43 (-0500), grarpamp wrote: >> >> The real problem below is the 96% allocation of opensource to >> Linux and 4% to Other opensource. > >> Someone should really do an analysis of platform vs. exit bandwidth >> as well. Anyone? > > Here ya go. Observed bandwidth per OS in relays having the exit flag: > > 93.62% 4459816582 Linux > 4.51% 214639363 FreeBSD > 1.25% 59672066 Windows > 0.25% 11754598 Darwin > 0.17% 7896687 Bitrig > 0.15% 6964863 OpenBSD > 0.06% 3091495 SunOS This excessive Linux dominance in both node count and bandwidth really should be balanced out, like why not? I'd expect if some of the big relays switch to any other OS that would flatten out the bandwidth part pretty easily. You'd have to check say the top 10, 25, 50 or so relays to see to what extent they are part of this mess, I'm sure it's similar.

1 0

Reverse Engineered Google Docs
by Александр 06 Nov '14

06 Nov '14

http://features.jsomers.net/how-i-reverse-engineered-google-docs/

1 0

open ASIC SoC
by coderman 06 Nov '14

06 Nov '14

given interest in open source privacy enhancing technologies, what about open ASIC SoC for privacy routers and other hw? - 32bit RISC opencores. http://cdn.opencores.org/pdf/or1k-asic.pdf - TRNG series as native instruction; avalanche + RF + slow sampled from fast pair into aligned memory target as raw samples, each source tunable via MSR. http://www.cryptography.com/public/pdf/VIA_rng.pdf , http://moonbaseotago.com/onerng/ - Fab with chain of custody via domestic 22-nm foundry services. (Intel, other?) - Random quality and critical component validation with a FEI Versa 3D tear down , http://siliconexposed.blogspot.de/2014/03/getting-my-feet-wet-with-invasive… what else required? (IOMMU isolation?)

3 6

cypherpunk consortium for carefree crossings
by coderman 06 Nov '14

06 Nov '14

regarding border crossing behaviors of the powers that be, it seems the most expedient response to detainments and data dupe'ings [0][1][2] is to answer with deterrent. possibilities to dissuade dastardly detours: - sunlight the best disinfectant; publicize attempts at intimidation and friction at crossings. - every detainment incurs a disclosure of intelligence collection technique. (requires a pool of un-disclosed spook ballast) - every detour spurs privacy enhancing technology development. a bounty for the most desired improvements, aggressive tactics lead directly to more users, better features, stronger privacy. other ideas? how many Tor trac tickets threatened to be develop to ensure ioerror a safe domestic passage? best regards, 0. "... her work has been hampered by constant harassment by border agents during more than three dozen border crossings into and out of the United States. She has been detained for hours and interrogated and agents have seized her computer, cell phone and reporters notes and not returned them for weeks." - https://en.wikipedia.org/wiki/Laura_Poitras#Government_surveillance 1. "I'm flying back to the US after writing about helping Ed Snowden and the journalists he leaked documents to. Wish me luck at the border." - https://twitter.com/micahflee/status/529191556897443840 2. "I'm looking forward to the time when we don't have to worry about politically motivated US border harassment. A distant time, probably." - https://twitter.com/ioerror/status/529206920838930433

2 1

Re: [tor-relays] [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by grarpamp 06 Nov '14

06 Nov '14

>> I'd agree simply because Windows presents a much larger attack surface. The >> amount of code running on a minimal Unix installation plus Tor is a lot less >> than a Windows system, especially network facing code. > ... > Running code, or network accessible code? Either way I don't see how > you came to that calculation. 'Minimal' Unix + Tor + SSH restricted > by SSH Key vs 'Minimal' Windows + Tor + RDP restricted by Client > Certificate. I also don't know what you mean by 'minimal' as very few > ... > I think a Windows Server, properly configured, is roughly as secure as > a properly configured Linux Server. > ... > I think there have been more bugs that result in RCE on production > Linux servers running SSH and a webserver in the past 4 years than > there have been in production Windows servers running RDP and IIS. > ... > I think if you're pointing fingers at China and the NSA, you should > assume they have RCE in both Windows and Linux. > ... > I think running relays on Windows Servers is no worse than running > relays on Linux Servers, and therefore it is good to do, because it > adds diversity to the network. Attack surface on a well adminned relay comes down to three things: - Network stack itself (kernel) - Daemon software itself (tor + remote admin) - Their respective use of other kernel/library/shell provided resources. I might suggest the current proportion of Windows to Linux is roughly ideal. This is primarily because, all other things set equal at 'minimal' (= tor + remote admin), good adminning, and good control of corporate secrets (or moles)... Windows still has one huge strategic weakness at that point... the magic packet. It's the whole binary vs. opensource argument. So essentially, the correct ratio of the two might be the odds you place that a binary OS has a magic packet. Today's node count shows 73% to opensource platforms. I'd suspect 73% is about where a lot of analysts might bet on Windows being magical, whether by/for the NSA, or any other reason or source. (Remember this... https://en.wikipedia.org/wiki/NSAKEY That was just from running 'strings'. Good luck trolling all of Windows with a disassembler... a nice fat payoff if you do. And the number of disassembling vs. opensource auditors is probably even more heavily skewed. And Windows is 'trusted' by buyers, nor can you replicate their binaries from any 'source code sharing agreements'. Then it's Patch Tuesday again... so it could be no one has or ever will disassemble audit it. So odds end up being pitched instead. And for many applications, that's good enough.) The real problem below is the 96% allocation of opensource to Linux and 4% to Other opensource. That's something that should be fixed. For these purposes, it doesn't matter which BSD/Other you pick... once you get the security odds there back towards say 50:50 Linux:Other, then you can debate userland and relative security amongst them all you want. Here's some links to get you started, including two other main branches of the Unix Kernel family tree at the bottom... 5939 Linux 1591 Windows 173 FreeBSD http://www.freebsd.org/ 56 Darwin 44 OpenBSD http://www.openbsd.org/ 7 NetBSD http://netbsd.org/ 6 SunOS 4 Bitrig https://www.bitrig.org/ 2 GNU/kFreeBSD https://www.debian.org/ports/kfreebsd-gnu/ 2 DragonFly http://www.dragonflybsd.org/ 0 Illumos (OpenSolaris) http://wiki.illumos.org/display/illumos/Distributions 0 Minix http://www.minix3.org/ Official metrics... https://metrics.torproject.org/network.html Someone should really do an analysis of platform vs. exit bandwidth as well. Anyone? Also, isn't there some project out there that is counting the historical number of kernel bugs+severity per OS over time? [To cpunks to cover all the other volunteer node based networks out there that could benefit from tuning their platform ratios.]

1 0