- cypherpunks - lists.cpunks.org

Re: [Cryptography] programable computers inside our computers (was: Hasty PRISM proofing considered harmful)
by Jerry Leichter 23 Oct '13

23 Oct '13

On Oct 22, 2013, at 9:50 PM, John Ioannidis wrote: > And to add another, there was a presentation on ARM TrustZone, the OS > inside your CPU, that's seems so designed for backdoors that ARM > actually gives tips for running TrustZone invisible to the normal OS. > https://www.hackinparis.com/sites/hackinparis.com/files/Slidesthomasroth.pdf > > > TrustZone sounds like Palladium from 15 or so ago. Have we learned *nothing*? Actually, there is a difference: Palladium had remote attestation built in - it was a selling point. People concentrated on that as the "bad" part, thought the rest could actually be useful. The reference designs let you do whatever you wanted with your own device - you have full access to the trusted elements, could sign your own boot loader if you wanted. Of course, someone providing DRM'ed material could refuse to talk to your system if it didn't attest to running "acceptable" code. The new technologies don't build remote attestation in, so avoid the whole debate. And the base technologies are neutral on the issue of whether you can write your own trusted code. It's the specific implementations that block you from changing the keys, the bootloader, any of the code running in the secure element, etc. The net effect is similar. Nothing keeps a system builder from including remote attestation, but because of the nature of the devices, who is doing the controlling (the cell service providers), and the much higher level of integration of the components (making it harder to pull pieces out of the controlled environment) it really doesn't much matter: If you're successfully talking to the cell network at all, they assume you have "approved" hardware. (Should people start building their own cell hardware from the ground up - certainly possible if you don't care about how practical the device is as a *cell phone*, but extremely difficult if you want something practical - they could always add remote attestation, or some simplified variant that's good enough for the cell provider's purposes, later.) Palladium was subject to political attack because it was open about what it could do for DRM suppliers. The new technologies are harder to attack this way because the responsibility is diffused, and the good and the bad are very thoroughly mixed together. The availability of secure modes in the hardware can be explained as necessary to allow for safe operation in an unsafe world, and in and of themselves harmless - just a safer extension of user space/kernel space isolation. The system builders build things to keep the systems safe from malware, a known and growing problem. The network providers want to protect their networks. Everyone sees the need for heavy protection - including from the device owner - of internal "wallets". -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [Cryptography] programable computers inside our computers (was: Hasty PRISM proofing considered harmful)
by Sebastian Krahmer 23 Oct '13

23 Oct '13

On Tue, Oct 22, 2013 at 12:29:33PM -0400, Tom Ritter wrote: [...] > On 22 October 2013 05:24, Ruben Pollan <meskio(a)sindominio.net> wrote: > > And to add another, there was a presentation on ARM TrustZone, the OS > inside your CPU, that's seems so designed for backdoors that ARM > actually gives tips for running TrustZone invisible to the normal OS. > https://www.hackinparis.com/sites/hackinparis.com/files/Slidesthomasroth.pdf > > These are increasingly worrying me as well. The Secure Element on > Android can at least (if you root and edit the .xml file) be queried > to learn identifiers of what is installed there, if not directly > interact with them. If you are really worrying about that, you are decades too late. :) ARM-TZ-alike features are already there in other CPU's called SMM, VT-x or SVM, or in your board called IPMI or AMT - or more generic OOB-Management. Or if you worry about phones its called SIM and SIM-toolkit (and this list is far from complete). Yes, if you want a real trustbase and crypto that stands, you have to open-source all of it. Do you know what your keyboard controller is doing? :) http://www.youtube.com/watch?v=tmZ4yXuDSNc Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer(a)suse.de - SuSE Security Team _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

[drone-list] Arizona military drone operators defraud USG for $1.4M
by Gregory Foster 23 Oct '13

23 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Stars and Stripes (Oct 21) - "21 members of Tucson Air Guard unit indicted on fraud charges": http://www.stripes.com/news/us/21-members-of-tucson-air-guard-unit-indicted… > Many allegedly received more than $100,000 by claiming they lived > in homes outside the Tucson area while on federal active duty > status at various times between November 2007 and September 2010, > officials said. > > “Some of these men and women received benefits in excess of four > and five-times their salaries in temporary duty entitlements,” > Horne said in a news release. "Conversely, our brave men and women > overseas were making pennies on the dollar compared to what this > group was receiving while still going home to their families each > night.” HT @Drone_Wars_UK: https://twitter.com/Drone_Wars_UK/status/392387301965185024 gf - -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSZ0VhAAoJEMaAACmjGtgj4hUQAJYWels3/jBHneS+e5vI5pa7 ltInMxRaQMp+pFevaMSGp6VMq3jNYQF+OaQG9Gw00m6SaQNKEy7I+mo2PpJXaQP2 MLmmniYWak3tzo6C+p5VVhpa3Z4UAkKrhMIUZFxxA0AjhjkSPOlh/jvfeVCTkgZZ 5QCXvY7PLqbqN6w29Il3rmlH3y7wVuUjM5dXl52VsT2Z2LVD2jB7a27xhQlXrXyQ jNS6IKtwoyE2UgTRQR4m9TFU2wWggmo0yoy4LeEeNyYEksxw2NTJA8JNKyzpkXbA l81XmDdOQXLlpJGoHer66AAgfW6aOqYfGtzm/fHlf/1CJ2n1kdgOhVJmpOb1pfk+ ui3q1BWbUjtI76v1OvBC5epUZKVqeAtLfWvjlU+1ptJWUNTlvtdbeCZo6xLXDHF5 7nAejLPpy3BdmwddD2hhmGsT6ILPQ/DfTSbeTKnktHTWZtpBlpocIn1+mN8Dil3A 2mOJIdGxg/o3GuGw/GFDRqKKhazeytymaQFI4uS6tU45p9DhSwbSwfl+YWGPI+uG qg85wa7H0qybfpBpxJByU4NpDzTMYgqv2A5OEnLjyjX0uqzJx/h46/NMuXWL1I3x VvubfqCBnAYAhymOvuH4kcm7/PWb0d8RqCLBgB7rsaOXqU98m7cH2awjnBbyjc/j R/ExiaAaEBuL6L48Aunu =vNqv -----END PGP SIGNATURE----- -- Want to unsubscribe? Want to receive a weekly digest instead of daily emails? Change your preferences: https://mailman.stanford.edu/mailman/listinfo/drone-list or email companys(a)stanford.edu

1 0

Re: [tor-talk] VOIP and tor
by Matt 23 Oct '13

23 Oct '13

On Tue, 22 Oct 2013 20:18:56 -0600 Mirimir <mirimir(a)riseup.net> wrote: > On 10/22/2013 06:52 PM, Andrew F wrote: > > > Is it the best to use for Voip call on tor? > > I think so. Because it can use UDP through the VPN tunnel, there's > virtually no break-up. Latency is high (1-2 seconds) but that's just a > fact of using Tor. You can set Mumble to TCP mode only and data and voice transmissions will both be sent using TCP. Running my own Mumble server as a hidden service, I got latency that was less than a second on fast circuits. -- 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

Re: [tor-talk] TBB and tor-relays as a bitcoin wallets
by grarpamp 23 Oct '13

23 Oct '13

On Oct 22, 2013 Joshua Datko <jbdatko(a)gmail.com> TOP POSTED!!! > Also, and I think this was discussed on this list before, offering payment > may actually decrease the number of volunteers [2]. > > I was initially interested in researching a technical way to offer payments > to relays by the clients joining a mining pool and somehow paying the relay > from the pool (something like ring signatures). But there is a lot of While waiting on a capitalist version of Tor, operators can publish their cryptocurrency address in the consensus. Users who wish to donate can write a controller script to match up relays they used with those accepting donations and send off some funds. There are already some addresses present. -- 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

Re: [tor-talk] VOIP and tor
by Mirimir 23 Oct '13

23 Oct '13

On 10/22/2013 06:52 PM, Andrew F wrote: > Is mumble secure over tor? I've used Mumble, with data transmission in UDP mode, on OpenVPN (in TCP mode) through Tor. Given that you, or someone whom you trust, are running the Mumble server, and that traffic is routed by VPN through Tor, I believe that it's secure. > Is it the best to use for Voip call on tor? I think so. Because it can use UDP through the VPN tunnel, there's virtually no break-up. Latency is high (1-2 seconds) but that's just a fact of using Tor. Voice quality is better than typical cellphone. Mumble was expressly designed for high-latency connections, so it has good interactive tools for optimizing voice quality. > What are the other options? I've heard good things about Jabber. However, all SIP apps depend on third party servers. And SIP servers are much harder to set up than Mumble servers. -- 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

Re: [Cryptography] programable computers inside our computers
by John Gilmore 23 Oct '13

23 Oct '13

> >> We thought embedded devices were for physical infrastructure > >> engineers to worry about, but now they are proliferating inside > >> our general purpose computers. The next Stuxnet will run on one > >> of the invisible computers inside your computer. It is probably ALREADY running there. With regard to the invisible single-chip computer that sits on every server's motherboard (thanks, you idiots at Intel), I can't say it any better than Dan Farmer: IPMI: Express Train to Hell, v2.0 dan farmer/zen(a)trouble.org http://fish2.com/ipmi/itrain-gz.pdf John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [zfs] [Review] 4185 New hash algorithm support
by Zooko Wilcox-OHearn 22 Oct '13

22 Oct '13

On Tue, Oct 22, 2013 at 6:05 AM, Schlacta, Christ <aarcane(a)aarcane.org> wrote: > > If any weakened algorithm is to be implemented, how can we know how weak is too weak, and how strong is sufficient? Each professional Cryptographer has given different opinions and all those at our immediate disposal have now been biased. A good way to do that is use an algorithm that has attracted interest from a large number of independent cryptographers. If many cryptographers have invested extensive effort trying to find weaknesses in a algorithm, and haven't reported any, then we can feel more confident that it is less likely to harbor undiscovered weaknesses. Among the algorithms we've been talking about in this thread, SHA-256, HMAC-MD5, Skein, Keccak, and BLAKE are all in this category of being well-studied. Cryptographers publish it if they find a weakness in a reduced-round variant of an important algorithm. You can see a summary of the best results against weakened variants of BLAKE in ¹ (Table 1). ¹ http://eprint.iacr.org/2013/467 The rows labeled "perm." and "cf." are attacks on just one component of the hash, not the whole algorithm. The "# Rounds" column shows how many rounds of a reduced-round variant would be vulnerable to that attack. Don't forget to look at the "Complexity" column, too! That shows (roughly) how many calculations would be necessary to implement the attack. Yes, almost all of them are computations that are completely impossible for anyone to actually execute in the forseeable future. But still, they are the best attack that anyone has (publicly) come up with against those weakened variants of BLAKE so they serve as a heuristic indicator of how strong it is. Among the well-studied algorithms listed above, BLAKE is one of the best-studied. It was one of the five finalists in the SHA-3 contest, and in the final report of the contest ², NIST wrote “The cryptanalysis performed on BLAKE […] appears to have a great deal of depth”. Here is a list of research reports that analyzed BLAKE: ³. ² http://dx.doi.org/10.6028/NIST.IR.7896 ³ https://131002.net/blake/#cr Now, BLAKE2 is not necessarily as secure as BLAKE. We could have accidentally introduced weaknesses into BLAKE2 when making tweaks to optimize it. The paper ¹ looked for such weaknesses and reported that they found nothing to make them distrust BLAKE2. We use a stream cipher named ChaCha ⁴,⁵ as the core of BLAKE and BLAKE2, and nobody has found any weakness in ChaCha. Again, that doesn't mean we didn't manage to screw it up somehow, but I think it helps! If anyone found a weakness in ChaCha, it would *probably* also show them a weakness in BLAKE2, and vice versa. ⁴ https://en.wikipedia.org/wiki/ChaCha_%28cipher%29#ChaCha_variant ⁵ https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-02 In sum, there has been a lot of independent analysis of BLAKE2, BLAKE, and ChaCha, and I hope there will be more in the future. If you use a reduced-round version of BLAKE2, you can look at these results to see whether anyone has published an attack that would break that reduced-round version. Of course, more rounds is safer against future breakthroughs. It was in that context that I recommended that ZFS use the most rounds of BLAKE2 that it can while still being faster than Edon-R. ☺ That will probably be around 5 rounds. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3… Powered by Listbox: http://www.listbox.com

1 0

TBB and tor-relays as a bitcoin wallets
by Trigger Happy 22 Oct '13

22 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, Just an idea. In theory : is it possible to implement bitcoin wallet into tor-relay and TBB 1) ? TBB users could tip tor-relays (f.e. 1 satoshi for guard and middle relay, 3 satoshi for exit-node per circuit). Running tor-relays could be profitable or at least cheaper. 1).I think Cody Wilson is working on a bitcoin wallet in a browser. - -- Trigger Happy jabber: triggerhappy(a)jabber.ccc.de torchat: xruq34bnhbqlkjtn -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSZo5zAAoJEEtm9wC9fGLFvF0P/3HYQSCcZea4iFeTygEkk1Fi s4Us35LVEMHeUx4fODEEXa4PlHMpHtitpBTa6yHRf+XsQLsvca4Xxvo5n1HMq09N FMK9JFFrItCdQO/T/lYNu9Tj3qLU34gpMlzsiN7u3fE8oALAyvHzyAmX0uaJM4Hk p5UsCU9REs5QBIjd8ZLqVodBPj5JHxRnyfxRhcHLZPb5WrrAluIwSOWeQW7GxhpL 3Hed2lZbcdaGyYGqTTBT6/C2KsMsvG097xTZXJKl+x7yL3521ceE9FW1zL7oTE3L i5PJpopbxjhqA3xH68RrSdw7L0Bbp79p3lRUzi4EC1DamHHhFal/tuRfJldhj3m1 4330nXP5pthqufJBql/lklkd7yG0exijq72I2nb9sb/SQLJG7LvF1ga0TKgoMAXC pKRy5NoMW6+UAHtSlFBmeOMKlxsFEbVRAGRhCBlQrbWOIuK+47VfGm7cDaQMID3T AAusJA5z6h+aZlncwyWiJohk753mnrON6lPBD0y9luHFusZ4eUL2Zzy+cqL27xBp mULJR9ABGKW4vndKBBLoH9/wDQmEm1ejL1+74BYRDZrO9mgBADjD50yc4RZ/sK6s JsX/KB/WOLSmYXdk28eS2k+YK+8ke8Y6kuZSAWqEuePqcHiM2+wyHLEhyE8Y7Shv 0JX2WiE0goClZOQfNRH7 =y5Ga -----END PGP SIGNATURE-----

1 0

[Cryptography] Mail Lists In the Post-Snowden Era
by Jerry Leichter 22 Oct '13

22 Oct '13

Perry re-started this mailing list in response to the Snowden revelations about the NSA's attacks on Internet cryptography. He raised the questions of whether we could make a Prism-proof Internet. That's a big problem, and we've been debating small pieces of it ever since. I'd like to suggest a smaller problem, just as a kind of rallying point. This list has certainly attracted NSA interest. Whether by subject, by keyword matching, or because so many of the participants here are clearly "adversaries" of those in the NSA responsible for gaining access to all that crunchy good stuff out there, there's no way anyone here could avoid scrutiny. So ... imagine we don't like that. How could this list be constituted in a "secure" way? The quotes are on "secure" because even the definition of the word isn't clear. Realistically, there's no way to avoid an NSA "plant" joining an open group, so perhaps there's little point in encrypting the messages. Anonymous/pseudonymous posting? Signed messages? (A few members post them; hardly any of us do.) Does that just make messages even more traceable/linkable? We think we know what it means to have secure 1-1 email. Adding a couple of additional participants seems as if it leaves the nature of the problem unchanged, but in fact you very quickly get into trust issues: In a 1-1 conversation, I can decide whether to trust my correspondent. In any multi-party conversation, it's likely that at least one of the participants doesn't know *all* the others, so must make an indirect trust decision: I trust him because the others here seem to trust him. For a mailing list, this problem explodes - while in addition there are all kinds of issue with how exactly to set up key exchanges. A moderated group like this could be looked at as a star configuration: In a way, each participant really only communicates with the moderator. But that seems to miss the point - despite the moderation, this group *feels* like a free-flowing conversation among a group of people. So what would a reasonable security model for the Cryptography list look like? Is it inherently just an open discussion? Or could we come up with something else? If we can do more, what kind of software would be needed to make it as free-flowing and easy to participate in and manage as the current list? -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

3 2