- cypherpunks - lists.cpunks.org

Fwd: [liberationtech] XMPP object encryption at IETF about to die...
by Griffin Boyce 12 Nov '14

12 Nov '14

FYI: -------- Original Message -------- From: Joseph Lorenzo Hall <joe(a)cdt.org> Sent: November 11, 2014 7:18:49 PM EST To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] XMPP object encryption at IETF about to die... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm here at IETF 91 hanging with all the protocol nerds. I was talking to someone about OTR and they pointed out that the object-encryption standard for XMPP that has been put forward is about to die due to lack of interest and engagement: http://tools.ietf.org/html/draft-miller-xmpp-e2e Has anyone seen this and thinks it could be a good thing to standardize? I realize it's a subset of what OTR provides but I'm wondering if this could be something we as a community might want to work with in this kind of standards body. Any e2e-has-a-posse folks have an interest here or is standardization not an interest or desire? best, Joe - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe(a)cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) iQIcBAEBCAAGBQJUYqdpAAoJEF+GaYdAqahxuxsP/iABSEXS2U9ZexGDyKCVdCKD uiOI7lLzXBta+BDqh3UPIdb2vyQDJLUcnYuYL2ywBy3vaPDdm3NZMnYEEG4Rg96+ Yg1xyJtNZXGD/qs+bLb3po87dJzHINif7gg+IQs9NmfPt+oEu6WJIBH5ZBzwweTy FI7uxCvAxEkweCj8XP5O40EZX416EIVBi2gR+IUXK2clxbPLBCeu59xzLSvp9/on TQgDVq6SO4kCoZNktuXg1b6aOUEnk8ZoQLFGwq/CRaw4zc6/FUI74dQ6jGSaMOHR Edr99rUEXPKqxPXnDsi8Rw/4bgWogP2qYEmdVhh7Y9kzkQmiSih3wVxutsHJ3Fb7 DamUjZQ+rdGv4AMwy1dDaSPw1ij2V7csYJl2mb3OXFHmB2V0RZBBNgvXduju3ThX h3xNU7VE/5r6vBSiYLDtqMY/UPwrYKsvJ/N2ditIxVmOgtKVEdnQHh3OVZlKfMDE LsaZjjmQNOJoUO/TyTic5kOjhcHLnhgRfVEedwniSStFYBqrPYrGnovAQn5mns6j FXTq29A3UT6aF1iawd0Ut9WxK4AhxzlH83ZaaURKFsLVkm5ycHfSgBUb+nz5fiPW +QTyExfhZxYo2fEUzPPwwGKwYc0Ytvif+GlxOP80VekS8R5ajI1J8xzHPtxLJQFI qXMnJu4ilQlRgLVhlztN =6app -----END PGP SIGNATURE----- -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu.

3 2

OpenBazaar Beta 3.0 “Tabriz” is released
by Eugen Leitl 11 Nov '14

11 Nov '14

https://blog.openbazaar.org/beta-3-0-tabriz-is-released/ Beta 3.0 “Tabriz” is released November 10, 2014 Sam Patterson The third OpenBazaar beta release is now available. With this release, we’re starting the tradition of naming our releases after great bazaars from all around the world, with the first being Tabriz, a market in Iran which is one of the oldest bazaars in the Middle East. Tabriz represents a significant amount of work for our developers, with more than 350 commits, and merging more than 70 pull requests from the community. We thank everyone who contributed. One of the major improvements in Tabriz is the ability to run on Windows. If you’d like to become a beta tester, download the Windows binary [signature here], unzip the file and run the OpenBazaar.exe file. In case our site goes down, you can get a torrent with this magnet link. For a full list of changes in Tabriz, check out the changelog. Testing If you want to become a beta tester and are running on Mac or Linux, follow these instructions in your terminal: If you don’t have Git installed on Linux, open terminal (Ctrl+Alt+T) and type: sudo apt-get install git If you don’t have Git installed for OSX, download here and install. Now run: git clone https://github.com/OpenBazaar/OpenBazaar.git Once that’s complete, change directories: cd OpenBazaar Run the configure with this command: ./configure.sh If you’ve already been running OpenBazaar, you need to update the code. In terminal, run the following commands: git pull ./configure.sh To start your node: ./openbazaar start To stop your node: ./openbazaar stop To get help on the commands you can use with OpenBazaar: ./openbazaar help If you find a bug, please let us know on our Github or on the bug reporting thread in our subreddit. 3.0 beta Tabriz

1 0

Operation Onymous
by Rich Jones 10 Nov '14

10 Nov '14

Many DNMs seized today, 26 y/o SpaceX engineer arrested in San Francisco, raids in Ireland, http://www.businessinsider.com/fbi-silk-road-seized-arrests-2014-11 SR2.0, Hydra and Cloud 9 are all display seized notices. TMP and Agora are still up. Here's the criminal complaint: http://www.scribd.com/doc/245744857/Blake-Benthall-Criminal-Complaint Full of all kinds of operational fuckuppery on all fronts. Sounds like they've got more in the pipeline too.. R

5 7

National Bank of Ukraine on Bitcoin
by Anton Nesterov 10 Nov '14

10 Nov '14

"...hryvnia is the only legal tender in Ukraine, adopted by all natural and legal persons without any restriction on all territory of Ukraine for the transfer and settlement. <...> Issuing and turnover any other currencies [besides hryvnia] and using of money surrogates for payments is forbidden<...> Given the above, National Bank of Ukraine considers "virtual currency/cryptocurrency" Bitcoin as a money surrogate that isn't providing real value and can not be used by individuals and entities on the territory of Ukraine for payments, because it is contrary to the norms of Ukrainian legislation. <...> However, the international distribution of such payments attractive for illegal activities, including money laundering and financing of terrorist activities. We emphasize that user is responsible for all the risks in use "virtual currency/cryptocurrency" Bitcoin. National Bank of Ukraine as a regulator is not liable for risks and losses associated with use of "virtual currency/cryptocurrency" Bitcoin. In order to protect consumers rights and safety of money transfer, National Bank of Ukraine encourages citizens to use services of only those payment systems/settlement systems, which included the National Bank's Registry of payment systems, settlement systems, participants in these systems and service providers of payment infrastructure." So it's not says Ukraine bans Bitcoin (some media already published such statements), it says Bitcoin already illegal in Ukraine, as any currency besides hryvnia, and says govt isn't responsible for any risks with using Bitcoin. Official statement: http://bank.gov.ua/control/uk/publish/article?art_id=11879608&cat_id=80928 (in Ukrainian) Law of Ukraine "About National bank of Ukraine": http://zakon2.rada.gov.ua/laws/show/679-14 (in Ukrainian) -- https://nesterov.pw GPG key: 0CE8 65F1 9043 2B11 25A5 74A7 1187 6869 67AA 56E4 https://keybase.io/komachi/key.asc

2 1

Fwd: [Cryptography] From IP: Peter Swire looking for crypto policy expertise....
by grarpamp 09 Nov '14

09 Nov '14

---------- Forwarded message ---------- From: Peter Trei <petertrei(a)gmail.com> Date: Sun, Nov 9, 2014 at 6:59 PM Subject: [Cryptography] From IP: Peter Swire looking for crypto policy expertise.... To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Slightly off-topic, but may be of interest to some: From: Peter Swire <peter(a)peterswire.net> To: Dave Farber <dave(a)farber.net> Date: November 7, 2014 at 8:46:30 AM EST Subject: request for assistance for debate on encryption with former FBI General Counsel Hello Dave: On Monday, November 17 the New America Foundation will be hosting a debate on the topic of FBI Director Comey’s criticisms of Apple and Google for the encryption changes to their phones. The moderator will be Nancy Libin, formerly of both CDT and the Department of Justice. Former FBI General Counsel Andrew Weissmann will be presenting the Comey side of the argument. Andrew is an experienced litigator, former head of the Enron Task Force and other major prosecutions. I was in school years ago with Andrew, and the debate will be on the merits but not personal. With that said, only the best arguments will work. With that in mind, I was wondering if readers of your list might send (off-list) resources to prepare for the debate? Many people, in diverse outlets, have been writing about these topics. Although I am currently in the midst of hiring a full-time researcher, I don’t have that help at the moment. If useful, I could circulate a bibliography once the debate happens. For those in DC, the debate will be 4:00 to 5:30 p.m. at New America, address 1899 L St. NW #400. it will be webcast, and may be on C-Span. Thanks, Peter _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [tor-talk] insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here]
by grarpamp 09 Nov '14

09 Nov '14

On Sun, Nov 9, 2014 at 11:08 AM, Andrea Shepard <andrea(a)torproject.org> wrote: > Yes, and that is what it looks like. The strings 'code', 'old' and 'fail' in > the URLs seen in nachash's logs were also present as top-level directories on > his site, and he apparently had a 404 redirect to his index page - so a > buggy crawler might well produce something like the observed pattern. Who > would leave an obviously broken crawler producing nothing of interest like > that running for such a long time and O(1M) requests, though? An attack > designed to look like skiddie bullshit is starting to sound plausible. > coderman: > morals of this story: > - never assume a crash or DoS is innocuous on the Tor network. > - always get packet captures to diagnose trouble! (not just request logs) > - "the old tricks, still the best tricks..." In one of many threads, mine being 'dirty pool', there is forming a good variety of such morals to live by and areas of action to pursue. HS operators banding together to compare the above logs is one of them. You could conceivably throw the logs/pcaps from many relays and onions into a splunk.onion instance and try to mine some knowledge out of them that way. Tor is a jointly owned wide area infrastructure... seems time to apply the traditional net/sec tools to it and see what's up on your own network.

2 1

Fwd: insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here]
by coderman 09 Nov '14

09 Nov '14

---------- Forwarded message ---------- From: coderman <coderman(a)gmail.com> Date: Sun, 9 Nov 2014 02:04:59 -0800 Subject: insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here] thanks for the transparency, nachash! i am putting this conversation on tor-talk, since my replies are more noise and less dev, and the details seem to be around Tor use and configuration. On 11/8/14, Fears No One <nachash(a)observers.net> wrote: > ... Another regret is that pcaps weren't taken, but we both made > the mistake of assuming that because the DoS was mitigated that nothing > that was preserved would be all that important anymore. If there was > more to give, we would have been released it. the pcap dumps would have been most useful, as the access logs only identify state transitions. these types of attacks likely utilized many concurrent requests (perhaps just sending a few bytes of the request string at once, bit by bit, until a request is complete) performance analysis and tuning of internet sytems is difficult, and even more so in this context! (and performance in anonymity systems is easily reversed for de-anonymizing DoS) Andrea's distribution shows this type of behavior, as i would expect it: https://people.torproject.org/~andrea/loldoxbin-logs/analysis/length_distri… e.g. send small bits to keep connection active and not closed by server side client send timeouts, then around 900-1000 chars call it good and finalize the request. this may be application of slowloris type DoS to "encourage" HS operator to use a vulnerable path, or confirm via side channel. (you stated your web server bound to localhost, so the obvious ones you avoided at least :) > The box was an OpenVZ VPS (Essentially a glorified chroot jail, for > those who are unfamiliar)), so no, there was no physical hardware from > my standpoint. Thus, full disk crypto wasn't really an option. From the > standpoint of someone with root access to a dedi with OpenVZ vms, > finding hidden services that are hosted by customers is a matter of > looking for files named private_key anywhere under the /vz folder. of all the virtualization environments, i dislike OpenVZ the most. i dislike all virtual hosting, however, so don't assume this is a vote for Docker ;) pay the extra for dedi on bare metal! > Neither of us are rolling in fake internet money like the drug market > operators (Hint: This should indicate to anyone thinking of asking if we > ran bitcoind that we didn'), so the other alternatives were to either > use rooted boxes or flip a coin to decide who gets to host from home. ok, maybe a dedi not an option if you're that tight for cash... :/ > ... As was the tradition with doxbin boxes, the registration info > usually either went back to ... Keith Alexander... i find this amusing! my only suggestion is that you incorporate his nickname, Keith "Cowboy" Alexander > I don't have an exact time, but by around 13:00 UTC or so on the 6th, > the box was down. When the Silk Road 2.0 seizure news broke, doxbin was > already gone. I checked the most current doxbin onion and attempted to > ssh into the box every couple of hours for around the first 24 hours, > until a friend pointed out that one of the old doxbin onions was serving > up the Silk Road 2.0 seizure page. At the time, the main onion was > serving up some 404 page (Which I expected to eventually point to some > sort of honeypot, but the pigs really let me down on that one), while > other onions were unresponsive. This had changed by the next day, when > all the onions from the doxbin box were pointed to the seizure page. The > speculation has been that the cops were adding onions one at a time, and > my personal experience supports that. Police who are dedicated to > seizing and taking control of hidden services are still struggling with > managing a torrc file efficiently. Go figure. yup. hence slappy fights over the HSDir descriptor publishing is going to be effective for who knows how long... > There was some downtime on the box maybe a month ago, which I originally > thought was when it got imaged pre-seizure, once all this drama began. I > can't look at the access log report numbers and say "This is the date, > because there's a huge dip in traffic" so I'm going to have to get back > with you on that. The fact that they were adding onions to the seizure > box over 24 hours after the takendown might suggest that they for some > reason didn't image it beforehand, which would be a curious break from > their habits as laid out in past criminal complaints. this was an international effort, so perhaps just one hand not talking to the other, is the only conclusion to be drawn. > An update: All of the access log reports ever generated for doxbin can > be now be downloaded from the URLs in my initial e-mail. Other people > wanted some of them to compare to the DoS log reports, so now they can > pick their own control group. thanks for this, while not as useful as PCAPs with headers, it is still useful! > P.S. Neither of us have been arrested or have even noticed any signs of > in-person heat (Cleaning vans, new neighbors, etc), which also seems to > point to the doxbin seizure being half-cocked. how would you know what covert heat looks like? *grin* > Here until I'm in handcuffs, don't plea out! P.S. public key? best regards,

1 0

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