- cypherpunks - lists.cpunks.org

[liberationtech] Setting up your own app store with F-Droid
by Nathan of Guardian 06 Nov '13

06 Nov '13

Useful HOWTO and new tools package by Hans for anyone who needs to distribute their own Android software, outside of Google Play, using the excellent F-Droid.org project. Clarification from below: While the US and Google no longer restrict access from Iran, the Google Play service is still unfortunately filtered and blocked there, and is increasingly facing app-specific filtering in other parts of the world (Viber downloads for Saudi Arabia, etc.) Ultimately, this is about a need to decentralize app distribution, while doing everything we can to ensure software security and verification for end-users. More from Hans... "The Google Play Store is not available in all parts of the world, the US restricts its use in certain countries like Iran, and many countries block access to the Play Store, like China. Also, the Google Play Store tracks it users actions, reporting back to Google what apps have been installed and also run on the phone. Because of the NSA leaks, we’re seeing that governments are actively tapping into the raw data streams of Google, Yahoo, and others. So that means that the information that the Google Play Store sends back to Google is also intercepted by the NSA and other country’s agencies like it, and they in turn also share that information with other governments. Lastly, the Google Play Store is not free software, unlike the core of Android itself. It is proprietary software that Google entirely controls. F-Droid is a wonderful, free app store for Android. It is modeled after Debian or other GNU/Linux distros in that it has its own package repositories (repos) and build servers for all the apps that are part of the official OS. Like Debian and Ubuntu, you can also setup your own repos for anyone to use. Any free software can be added to the official F-Droid repos, where they are built and signed by the F-Droid server. This can be annoying because it means that your apps in F-Droid are signed by a different key than your apps in the Google Play Store. If you host your own F-Droid repo, then people can use F-Droid to install your own builds signed by your own signing key. This is a quick HOWTO for how to setup such a repository on a Debian or Ubuntu box." https://guardianproject.info/2013/11/05/setting-up-your-own-app-store-with-… -- 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.

1 0

[tor-talk] Tor Weekly News — November 6th, 2013
by dope457 06 Nov '13

06 Nov '13

======================================================================== Tor Weekly News November 6th, 2013 ======================================================================== Welcome to the nineteenth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the up-to-date Tor community. Tails 0.21 is out ----------------- The Tails developers anounced the 34th release [1] of the live system based on Debian and Tor that preserves the privacy and anonymity of its users. The new version fixes two holes that gave too much power to the POSIX user running the desktop: Tor control port cannot be directly accessed anymore to disallow configuration changes and IP address retrieval, and the persistence settings now requires privileged access. On top of these specific changes, the release include security fixes [2] from the Firefox 17.0.10esr release and for a few other Debian packages. More visible improvements include the ability to persist printer settings, support for running from more SD card reader types, and a panel launcher for the password manager. For the curious, more details can be found in the full changelog [3]. As with every releases: be sure to upgrade! [1] https://tails.boum.org/news/version_0.21/ [2] https://tails.boum.org/security/Numerous_security_holes_in_0.20.1/ [3] https://git-tails.immerda.ch/tails/plain/debian/changelog New Tor Browser Bundles based on Firefox 17.0.10esr --------------------------------------------------- Erinn Clark released new versions of the Tor Browser Bundle [4] on November 1st. The previously “beta” bundles have moved to the “release candidate” stage and are almost identical to the stable ones, except for the version of the tor daemon. A couple of days later, David Fifield also released updated “pluggable transport“ bundles [5]. The new bundles include all security fixes from Firefox 17.0.10esr [6], and updated versions of libpng, NoScript and HTTPS Everywhere. It also contains a handful of improvements and fixes to the Tor Browser patches. Users of older version of the Tor Browser bundles should already have been reminded to upgrade by the notification system. Don't forget about it! This should be the last bundles based on the 17 branch of Firefox as it is going to be superseded by the 24 branch as the new long-term supported version in 6 weeks. Major progress has already been made by Mike Perry and Pearl Crescent to update the Tor Browser changes and review the new code base [7]. [4] https://blog.torproject.org/blog/new-tor-browser-bundles-firefox-17010esr [5] https://blog.torproject.org/blog/pluggable-transports-bundles-2417-rc-1-pt1… [6] https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html#fire… [7] https://trac.torproject.org/projects/tor/query?keywords=~ff24-esr Monthly status reports for October 2013 --------------------------------------- The wave of regular monthly reports from Tor project members for the month of October has begun early this time to reach the tor-reports mailing-list: Damian Johnson [8], Linus Nordberg [9], Karsten Loesing [10], Philipp Winter [11], Ximin Luo [12], Lunar [13], Kelley Misata [14], Matt Pagan [15], Sherief Alaa [16], Nick Mathewson [17], Pearl Crescent [18], George Kadianakis [19], Colin Childs [20], Arlo Breault [21], and Sukhbir Singh [22]. [8] https://lists.torproject.org/pipermail/tor-reports/2013-October/000367.html [9] https://lists.torproject.org/pipermail/tor-reports/2013-October/000369.html [10] https://lists.torproject.org/pipermail/tor-reports/2013-October/000370.html [11] https://lists.torproject.org/pipermail/tor-reports/2013-November/000371.html [12] https://lists.torproject.org/pipermail/tor-reports/2013-November/000372.html [13] https://lists.torproject.org/pipermail/tor-reports/2013-November/000373.html [14] https://lists.torproject.org/pipermail/tor-reports/2013-November/000374.html [15] https://lists.torproject.org/pipermail/tor-reports/2013-November/000375.html [16] https://lists.torproject.org/pipermail/tor-reports/2013-November/000376.html [17] https://lists.torproject.org/pipermail/tor-reports/2013-November/000377.html [18] https://lists.torproject.org/pipermail/tor-reports/2013-November/000378.html [19] https://lists.torproject.org/pipermail/tor-reports/2013-November/000379.html [20] https://lists.torproject.org/pipermail/tor-reports/2013-November/000380.html [21] https://lists.torproject.org/pipermail/tor-reports/2013-November/000381.html [22] https://lists.torproject.org/pipermail/tor-reports/2013-November/000382.html Tor Help Desk Roundup --------------------- One person asked why the lock icon on the Tor Project's website was not outlined in green. Sites that use HTTPS can purchase different types of SSL certificates. Some certificate issuers offer certificates that supply ownership information, such as the physical address of the website operator, for a higher price. Sites that use these certificates get the lock icon by their URL outlined in green. The Tor Project adds protection to the validity of our SSL certificate a different way, by supplying our SSL certificate fingerprint on our FAQ page [23]. You can double check that fingerprint on any of the Tor Project's mirror pages as well [24]. One person wanted to known why a website they were visiting over Firefox was telling them that they were not using Tor, even though Vidalia told them that Tor was running. By default, the Tor Browser Bundle does not anonymize all the traffic on your computer. Only the traffic you send through the Tor Browser Bundle will be anonymized. If you have Firefox and the Tor Browser open at the same time, the traffic you send through Firefox will not be anonymous. Using Firefox and Tor Browser Bundle at the same time is not a great idea because the two interfaces are almost identical, and it is easy to get the two browsers mixed up, even if you know what you are doing. [23] https://www.torproject.org/docs/faq.html.en#SSLcertfingerprint [24] https://torproject.org/getinvolved/mirrors.html.en Miscellaneous news ------------------ The third beta release of TorBirdy has been released [25] as version 0.1.2. Among several other fixes and improvements it restores proper usage of Tor when used with Thunderbird 24. Be sure to upgrade [26]! [25] https://blog.torproject.org/blog/torbirdy-012-our-third-beta-release [26] https://www.torproject.org/dist/torbirdy/torbirdy-0.1.2.xpi starlight reported [27] on running a Tor relays with the daemon compiled with the AddressSanitizer [28] memory error detector available since GCC 4.8 [27] https://lists.torproject.org/pipermail/tor-relays/2013-October/003187.html [28] https://code.google.com/p/address-sanitizer/ Isis Lovecruft has sent two proposals [29] for improvements to BridgeDB. One is finished and addresses the switch to a “Distributed Database System and RDBMS”. The second is still in draft stage and “specifies a system for social distribution of the centrally-stored bridges within BridgeDB”. [29] https://lists.torproject.org/pipermail/tor-dev/2013-November/005713.html Karsten Loesing announced [30] the availability of a new tech report he wrote with Steven J. Murdoch, and Rob Jansen: “Evaluation of a libutp- based Tor Datagram Implementation” [31]. Be sure to have a look if you are interested in one of the “promising approach to overcome Tor’s performance-related problems”. [30] https://lists.torproject.org/pipermail/tor-dev/2013-October/005700.html [31] https://research.torproject.org/techreports/libutp-2013-10-30.pdf SiNA Rabbani has been asking [32] for comments on two documents he wrote about how use cases and design of a “point-and-click” hidden service blogging tool, as part of the Cute Otter project [33]. [32] https://lists.torproject.org/pipermail/tor-dev/2013-October/005703.html [33] https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter… David Goulet released third rc of Torsocks 2.0.0 [34] with a lot of fixes and improvements. Available to download from GitHub [35] and also as Debian package from the experimental distribution [36]. [34] https://lists.torproject.org/pipermail/tor-dev/2013-November/005728.html [35] https://github.com/dgoulet/torsocks/archive/v2.0.0-rc3.tar.gz [36] http://packages.debian.org/experimental/torsocks Christian is working on a new round of improvements for Globe [37], a web application to learn about relays and bridges of the Tor network. The project seems close to be mature enough to replace Atlas [38] according to some. [37] https://lists.torproject.org/pipermail/tor-dev/2013-November/005725.html [38] https://lists.torproject.org/pipermail/tor-dev/2013-November/005735.html A discussion on the tor-relays mailing list prompted Roger Dingledine to ask about changing the current default exit policy [39] of the tor daemon. The current “restricted exit node” policy has been in place since 2003. As this has surprised some operators, switching the default policy to “middle node” is under consideration. [39] https://lists.torproject.org/pipermail/tor-relays/2013-November/003240.html Upcoming events --------------- Nov 05-07 | 20th ACM Conference on Computer and Communications Security | Berlin, Germany | http://www.sigsac.org/ccs/CCS2013/ | Dec 27-30 | Tor @ 30th Chaos Communication Congress | Hamburg, Germany | https://events.ccc.de/congress/2013/ This issue of Tor Weekly News has been assembled by Lunar, dope457, Matt Pagan, and Philipp Winter. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [40], write down your name and subscribe to the team mailing list [41] if you want to get involved! [40] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [41] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

[Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
by Matt Corallo 06 Nov '13

06 Nov '13

Recently, there has been a reasonable amount of discussion about the continued fragility of the public Bitcoin network on IRC and elsewhere (1). To this extent, I'm organizing a system of peering between nodes in the network by creating a system of high-speed relay nodes for miners and merchants/exchanges. This system will a) act as a fallback in the case that the public Bitcoin network encounters issues and b) decrease block propagation times between miners. It is NOT designed to in any way replace or decrease the need for the public Bitcoin P2P network. It is NOT any kind of attempt at centralization, and I still encourage interested parties to establish their own private peering agreements with large miners as needed. Currently the network consists of one specially-designed relay node, but I hope to bring more online in the coming days. This network is open to everyone via a few public relay nodes, but also will have nodes which are made available only to large miners and merchants/exchanges to mitigate the ability of malicious parties to DoS the network. To peer with the public relay nodes, simply select the closest region out of us-west (West Coast US), us-east (East Coast US), eu (Western Europe), au (Australia), or jpy (Japan) and add public.REGION.relay.mattcorallo.com to your addnode list. Note that since all of the relay nodes will relay between each other, you gain no latency advantage by peering with more than the closest node to you (and currently all the regions map to one node, so there they're redundant anyway). For each relay node, you can connect to either port 8334 or 8335. Connecting on port 8334 will relay only blocks, and port 8335 will relay both blocks and transactions. The relay nodes will request any transactions which appear in your invs no matter which port you connect to. Relay node details: * The relay nodes do some data verification to prevent DoS, but in order to keep relay fast, they do not fully verify the data they are relaying, thus YOU SHOULD NEVER mine a block building on top of a relayed block without fully checking it with your own bitcoin validator (as you would any other block relayed from the P2P network). * The relay nodes do not follow the standard inv-getdata-tx/block flow, but instead relay transactions/blocks immediately after they have done their cursory verification. They do keep some track of whether or not your nodes claim to have seen the transactions/blocks before relaying, but you may see transactions/blocks being sent which you already have and have not requested, if this is a problem for you due to bandwith issues, you should reconsider your bandwith constraints and/or are peering with too many nodes. * The relay nodes will all relay among themselves very quickly, so there is no advantage to peering with as many relay nodes as you can find, in fact, the increased incoming bandwidth during block relay spikes may result in higher latency for your nodes. * The relay nodes are NOT designed to ensure that you never miss data, and may fail to relay some transactions. Additionally, because the relay nodes do not respond to standard getdata requests, if you miss a relay and then reconnect, that data will not be sent again by the relay nodes. The relay nodes are NOT a replacement for having peers on the standard P2P network, they are only there to augment the existing P2P network. If you are a merchant/exchange/large miner/other important node operator and wish to gain access to additional domain names which map to relay nodes with fewer peers, please fill out the form at https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8… You can find the source for the relay nodes at https://github.com/TheBlueMatt/RelayNode If you have any comments/concerns/suggestions, please do not hesitate to email bitcoin-peering(a)mattcorallo.com Thanks, Matt (1) There has been extended discussion on #bitcoin-wizards as well as #bitcoin-dev of the very small number of active, listening nodes. Additionally, because many of those nodes are versions prior to 0.8.4, it seems very likely that maliciously creating network splits or at least drastically reducing the number of peers for most nodes would not be particularly challenging in the current network. Also, http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041… noted that they were able to single-handledly decrease the network-wide orphan rate by around 50% by improving network peering. Finally, you've all seen the recent discussion on malicious mining algorithms. Though those are not entirely prevented by reducing block propagation times, they can be significantly limited compared to the current, rather disjoint, network. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

1 0

[Bitcoin-development] we can all relax now
by kjj 06 Nov '13

06 Nov '13

One of the things that really gets me going is when someone devises a model, tests it against itself, and then pretends that they've learned something about the real world. Naturally, the Selfish Mining paper is exactly this sort of nonsense. Their model is one with no latency, and one where the attacker has total visibility across the network. An iterated FSM is not a suitable simulation of the bitcoin system. The bitcoin network does not have states, and to the extent that you can pretend that we do, you can't simulate transitions between them with static probabilities. The authors understand this deep down inside, even though they didn't work out the implications. They handwave the issue by assuming a total sybil attack, and in true academic spirit, they don't realize that the condition necessary for the attack is far, far worse than the attack itself. Greg said he'd like to run some simulations, and I'm thinking about it too. Unfortunately, he is busy all week, and I'm lazy (and also busy for most of tomorrow). If neither of us get to it first, I'm willing to pitch in 1 BTC as a bounty for building a general bitcoin network simulator framework. The simulator should be able to account for latency between nodes, and ideally within a node. It needs to be able to simulate an attacker that owns varying fractions of the network, and make decisions based only on what the attacker actually knows. It needs to be able to simulate this "attack" and should be generic enough to be easily modified for other crazy schemes. (Bounty offer is serious, but expires in one year [based on the earliest timestamp that my mail server puts on this email], and /may/ be subject to change if the price on any reputable exchange breaks 1000 USD per BTC in that period.) Basically, the lack of a decent network simulator is what allowed this paper to get press. If the author had been able to see the importance of the stuff he was ignoring, we wouldn't be wasting so much time correcting him (and sadly the reporters that have no way to check his claims). https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663 ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

1 0

Re: [Cryptography] randomness +- entropy
by Jerry Leichter 05 Nov '13

05 Nov '13

On Nov 4, 2013, at 2:21 PM, John Denker wrote: > Some people have been throwing around the word "entropy" > rather carelessly. > > Entropy means something very special. Well, yes, and in its technical definitions - either in thermodynamics where it arose or information theory where it was imported because of a similarity in formalisms - it plays virtually no role in cryptographic discussion. In cryptography, especially when discussing random number generators, the word has a loosy-goosy meaning that's somehow tied to lack of predictability - but in an unspecified way. When people make it a regular habit to "guess" the entropy of various processes and then go on to build systems based on guesses, you know the word has lost any formal meaning it ever had. While the distinctions you draw are valid and important, I'm afraid "entropy" no longer has the capability to distinguish them. > For a great many cryptological purposes, a high-quality > PSEUDO-random distribution is good enough, even though its > entropy density is very low. Note the contrast: > > TRNG entropy density = 1 - epsilon > PRNG entropy density = epsilon I don't know what this means. > As another way of emphasizing the distinction: a PRNG places > orders-of-magnitude harsher demands on the strength of the > cryptological primitives it uses. I don't know what *this* means either. I drew a distinction in an earlier post - a distinction you can find in many papers on cryptographic primitives - between random values (unpredictable to the attackers being considered) and nonces (never repeated in a given cryptographic context, but there are no assumptions about unpredictability). Where a random n-bit value is specified, I can think of no paper that does not assume what we call "n bits of entropy" - though a better way to say it is "a value chosen uniformly at random from the set of n-bit strings". Sometimes the value is supposed to be chosen uniformly at random from some other set - e.g., from Z/p, i.e., between 0 and p-1. Trying to state this in terms of entropy is a losing game - and in fact it isn't actually trivial, given a random *bit* source, to produce such a distribution. People have gotten it wrong in the past. (The obvious technique of choosing a k with 2^k > p, choosing a "random" k-bit value, and the n reducing it mod p, if described in terms of "entropy", looks fine - I have k bits of entropy, which is more than enough to cover the choice I need to make. But the output is biased.) > This can be quantified > in terms of classical cryptologic ideas such as unicity > distance, but for present purposes I prefer the "entropy > density" language. "Unicity distance" is a nice but different concept - and one with little bearing on cryptography today. (If I draw a cipher E at random from some a collection of functions - e.g., by choosing a key - then the unicity distance is the unicity distance is just the number of pairs (x, E(x)) that specify E uniquely within the set. I suppose you can stretch this to talk about how many samples from the "random" generator are needed to specify *it* uniquely - i.e., be able to determine all past and future states - but I've seen the term used that way.) A broader - hence more useful - classical term (which may have been introduced by Shannon) is "equivocation". I don't recall the formal definition, but it attempts to capture the uncertainty an attacker has about the next plaintext, given all the information he already has. If I know a message was encrypted using a one-time pad, my uncertainty about the first character is not absolute - it's much more likely to be "t" than "z". T o provide information-theoretic security, a one-time-pad must contain "enough randomness" to keep my a priori and a postiori equivocation equal. This *is* something that can be given in terms of the entropies of the message and one-time-pad sources, but the deracinated notion of "entropy" one sees in most discussions is way too weak to say anything useful here.) > The rubber meets the road here: Consider the contrast: > > PRNG: I am quite sure that on startup the machine needs to > have on board a crypographically strong, well-seeded PRNG. > This needs to be up and running very, very early in the > boot-up process. Some things that need the PRNG cannot > wait. > > TRNG: At the moment I have no firm opinions as to how much > actual entropy the machine needs on start-up. I look > forward to having a discussion on this topic, with use-case > scenarios et cetera. A BBS generator is "indistinguishable" from a true random number generator. What's missing from that statement - and from the distinction you're drawing above - is a specification of the attack model. The BBS generator has inherent limitations that are given in its proof of correctness: The attacker has polynomially bounded resources (in fact, "attacker" literally means a polynomially-bounded probabilistic TM), which in turn implies that it only has access to a polynomially-bounded number of outputs. These are generally fine. The proof doesn't bother to state (though it's implicit) the obvious: That the attacker doesn't have access to the internal state of the generator. This isn't an "entropy" assumption - the internal state must, to the attacker, appear to have been chosen uniformly at random from all possible internal states, and is not available to the attacker. If you want to use "entropy-talk", all the entropy in a BBS generator is there, at the start, in the choice of the initial state. And yet there's a profound difference between the output of a BBS generator and the output of, say, a linear congruential PRNG starting with exactly the same state. One is pr edictable given a few successive samples; the other is secure given any polynomially-bounded number of them. "Entropy" simply cannot capture this distinction. And it's in fact exactly the distinction - in the transition from Shannon's classic notions of information-based security to modern computability-based ones - that make it possible to say anything useful at all about encryption algorithms other than one-time-pads. While we have no proofs like those for BBS for PRNG's built on practical cryptographic primitives, we generally assume that they have similar properties. (More correctly, we can prove some properties given assumptions about others. But those are the same assumptions we make about the actual encryption and hashing and signature algorithms we use. If they fail, the whole system falls down regardless of the source of "random" values.) To summarize: The distinction between cryptographic PRNG's and "true" RNG's has to do with the attack model. The attacker considered in the former is polynomially bounded (OK) and doesn't receive as input some special piece that we label "internal state" (this one can be violated). The attacker against a "true" RNG is ... what? Formalizing that is equivalent to formalizing randomness - which no one has managed to do. (In fact, modern developments of probability theory don't even try - random distributions are simply among the axioms. Even more, if you believe John Conway, the "Free Will" Theorem he and he and Simon Kochen proved show that "quantum unpredictability" is *stronger* than randomness!) In practical cryptography, this translates into "whatever I can imagine". In my other thread on plausible attacks, I tried to focus on limiting the attacker to, well, plausible operations in a particular real-world setting. If you *don't* do that, you can make no progress at all. A hardware generator - even Turbid - is vulnerable if I include as plausible an attacker who's infiltrated every supplier of electronic components in the world and has slipped a small transmitter into everything built, including every diode, resistor - hell, maybe every piece of wire! I have no problem with designing strong, practical random number generators. I'd love to see them deployed more widely. But clever designs of low-level primitives, as important as they are, are not a substitute for *system* designs; in fact, they can blind us to the necessary system properties. If a cryptographic primitive needs some unpredictable input, we need to go further and ask (a) how much? (b) unpredictable under what attack model? Only then can we begin to answer the *system* design question of "what's a suitable generator for such inputs?" If we can, for a reasonable cost (measured in any appropriate way), get our hands on a generator whose attack model assumes way more attacker resources than attacks on multiple uses of those values - great, let's make use of it. Too much discussion of "random number generators" is the equivalent of "I'm not sure AES is strong enough, so I'll do a ROT-13 encoding first - it can't hurt". And it can't - until you run into Tony Hoare's comment to the effect that "You can make a system so simple that you can see at a glance that it's correct, or so complex that you can't see at a glance that it's *not* correct." -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

2 1

key challenge results
by coderman 05 Nov '13

05 Nov '13

vast majority of players (63*) were able to encrypt to my key even though the email address did not match. (no address would, nor could you query a key server for it) this is a much better result than i expected, as some "friendly" clients have trouble encrypting without an email match. the onion reference a ruse, misdirection. hidden services not required to encrypt ;) same for invalid creation date, however, i'd love to know if anyone had a client complain on create date. as for the rest, i did enjoy the quotation discussion tangent! best regards, --- *unofficial tally: 63 successful players 3 failed attempts 1 anon recipient (extra credit :) clients (unverified) including: GnuPG, BCPG, OpenPGP.js, Why do you need to know? on platforms spanning Linux, BSD, Windows, OSX.

1 0

[Cryptography] Embedded device key generation problems due to bad PRNGs
by Bill Frantz 05 Nov '13

05 Nov '13

<https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic…> describes net scans for bad RSA keys on the web performed by Zakir Durumeric, Eric Wustrow, Alex Halderman, and Nadia Heninger. Among their conclusions: We manually verified that 59,000 duplicate keys were repeated due to entropy problems, representing 1% of all certificates, or 2.6% of self-signed certificates. We also found that 585,000 certificates, or 4.6% of all devices used the default certificates pre-installed on embedded devices. More surprisingly, we discovered that entropy problems can allow a remote attacker with no special access to factor a significant fraction of the RSA keys in use on the Internet. We were able to factor 0.4% of the RSA keys in our SSL scan. We did this by computing the greatest common divisor (GCD) of all pairs of moduli from RSA public keys on the Internet. However, there’s no need to panic as this problem mainly affects various kinds of embedded devices such as routers and VPN devices, not full-blown web servers. The list of vulnerable devices that we have already identified includes more than thirty different manufacturers, including almost all of the biggest names in the computer hardware industry. The kinds of products that we identified include firewalls, routers, VPN devices, remote server administration devices, printers, projectors, and VOIP phones. This is a problem, but it’s not something that average users need to worry about just yet. However, embedded device manufacturers have a lot of work to do, and some system administrators should be concerned. This is a wake-up call to the security community, and a reminder to all of how security vulnerabilities can sometimes be hiding in plain sight. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Airline peanut bag: "Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345 Englewood Ave www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032 _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [Cryptography] randomness +- entropy
by Theodore Ts'o 05 Nov '13

05 Nov '13

On Mon, Nov 04, 2013 at 12:21:00PM -0700, John Denker wrote: > > FWIW note that current Linux distros make no attempt to > provide a reservoir of true-randomly distributed bits for > use at the next startup. There are some efforts toward > storing a seed for the kernel PRNG, but the stored seed is > itself pseudo-randomly generated, and the kernel correctly > attributes zero entropy to it. One of the reasons why we don't attempt to extract "true random bits" and save them across a reboot is that even we had such bits that were secure even if the underlying crypto primitives were compromised to a fare-thee-well, once you write them to the file on the hard drive and the OS gets shut down, there's no guarantee that an adversary might not be able to read the bits while the OS is shut down. Even if you don't do something truly stupid (such as leaving your laptop unattended in a hotel room while visiting China), the risk of having your "true random bits" stolen is probably higher than the cryptographic primitives getting compromised. That's probably one of the reasons why people tend to not necessarily worry about the difference between a CSRNG and a TRNG in practice. For example, these are the people who believe that we should just replace Linux's /dev/random with a Fortuna RNG which doesn't even pretend to try to track entropy estimates, and which fundamentally assumes that the underlying crypto algorithms are secure, or at least, not the weakest link to worry about. (Again, realistically, the chances that your OS kernel has some 0-day vulnerability that the NSA's Tailored Access Operations folks have purchased from some black hat is probably a bigger risk than there being a cryptographic weakness in AES or SHA that is exploitable given the how we are using the encryption or crypto hash in Yarrow, Fortuna or Linux's /dev/random.) I still think it's worth it to have a /dev/random where we attempt to make an estimate of the entropy that we've collected and then later dispensed. But I recognize that from a engineering perspective, the distinction is not going to be that important for many people who are interested in practical security issues. Regards, - Ted _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

"Reforms" to NSA spying
by Jim Bell 04 Nov '13

04 Nov '13

A few days ago I read of 'reforms' being proposed to NSA spying on phone and internet metadata, along the lines of requiring the government to obtain some sort of warrant to get data from the phone companies, etc. Progress? I doubt it. Looks to me like the government knows it's going to lose control of the data, and probably there are no requirements that such phone co's keep 'all' the data. I predict that any proposed new bill will contain requirements that the phone co's record 'all' of the data the government might want, and keep it for an extended period of time. The government knows that if no such requirement is put into law, phone co's will compete for customers by offering ever-more-complete privacy. Soon enough, no phone company will store metadata, or they will store it in such a way that it will be useless for government purposes. Jim Bell http://news.yahoo.com/big-us-tech-firms-calls-reform-snooping-161145013.htm

3 2

NSA - What for.
by Juan Garofalo 04 Nov '13

04 Nov '13

What's the purpose of all the US spying? It obviously is not directed against 'terrists' since the only real terrorist out there are the american military sacks of shit and their accomplices. There are no 'foreign' terrorists who want to attack the US. If 'terrists' really existed, we'd be seeing real terrorist attacks in US cities every week. But there are none. So, are they spying on ordinary american subjects? What for? I mean, what actual benefit are they getting from that? They are the ones who caught DPR. But are they going to use their 'secret' information to put in jail every 'criminal' in the US? Or are they spying on behalf of american business, stealing industrial secrets and information from the competitors of american industries? Or are they mostly a useless bureaucracy that only steals and stores data, not doing anything else, at least for the time being? Preparing to transform the US from a covert totalitarian shithole into an overt totalitarian shithole? Or? J.

6 5