Re: [cryptography] Preserve us from poorly described/implemented crypto
On Tue, Jun 07, 2011 at 05:18:42PM -0400, Steven Bellovin wrote: > > Remember how well the original IBM PC "clicky keyboard" went over (I think > > I'm the only person in the US who actually liked it - veryone gave me > > theirs after "upgrading to the newer lightweight and silent ones) > > I"m typing on a large, heavy, clicky IBM keyboard right now... I stocked up on Model M SpaceSavers and full-size Model M's some 15 years ago. Have moved to Cherry MX (not blues, SteelSeries) gold crosspoints only a few weeks ago. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
On Sat, Jun 11, 2011 at 02:16:55AM -, John Levine wrote: > In article <021ccba9-9203-4896-8412-481b94595...@cs.columbia.edu> you write: > >http://gcn.com/articles/2011/06/09/bitcoins-digital-currency-silk-road-charles-schumer-joe-manchin.aspx?s=gcndaily_100611 > > I wouldn't call bitcoins digital cash. They're more like digital > tulip bulbs, or bearer shares of theglobe.com. > > Whatever they are, it's a self limiting problem since the bubble will > burst soon enough. Unlike fiat currencies, algorithms assert limit of total volume. And the mint and transaction infrastructure is decentral, so there's no single point of control. These both are very useful properties. I don't expect Bitcoin to be it, but it is definitely a predecessor to a number of such currencies which will become practical both for machines and people. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
On Sat, Jun 11, 2011 at 03:58:07PM +1200, Peter Gutmann wrote: > "John Levine" writes: > > >I wouldn't call bitcoins digital cash. They're more like digital tulip > >bulbs, > > Finally an analogy I can use to explain bitcoin to the masses (well, assuming > they know about the tulip mania). I've been using Bartercard, which is a > good > analogy but somewhat limited in international recognition. Tulips were an investment bubble, not means of payment. People are so quick to trust alternative local currencies and digital currencies because the official currencies have issues with being gamed (e.g. built-in inflation tax). For Bitcoin & Co to be usable e.g. in online transcations it doesn't have to be tradeable with real currencies. The reason it's risen to be, and so quickly, is merely due to a large demand. Now that people know the demand is fillable, there will be alternatives, particularly, if Bitcoin is attacked. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] attacks against bitcoin
How safe is the bitcoin cryptosystem and the communication network against targeted attacks? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] RDRAND and Is it possible to protect against malicious hw accelerators?
On Sat, Jun 18, 2011 at 07:16:39PM -0500, Marsh Ray wrote: > Intel bought McAfee a while ago. Speaking informally with some chip > people (not necessarily from Intel and definitely not under any > confidentiality) there's active research around the idea of building > instruction stream validation in support of antivirus directly into the The worst idea I've heard in a long time. > processor. Recognizing an intentionally-obfuscated virus seems no easier > than recognizing AES. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] bitcoin scalability to high transaction rates
On Wed, Jul 20, 2011 at 11:56:06AM +0200, Alfonso De Gregorio wrote: > I'd better rephrase it in: expectation to have "money backed by > bitcoins" exhibiting all the desirable properties of a perfect > currency (ie, stable money) are greatly exaggerated. The question is not whether it's perfect, but whether it's good enough. BTC is basically a global version of http://en.wikipedia.org/wiki/Local_currency or http://en.wikipedia.org/wiki/Alternative_currency and hence isn't something completely new. It would be intesting to see whether BTC's successors could improve the scheme, by allowing a (subexponential) growth, built-in devaluation to encourage circulation and discourage hoarding (this would be probably hard to do), and so on. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] bitcoin scalability to high transaction rates
On Thu, Jul 21, 2011 at 09:52:27AM +1000, James A. Donald wrote: > But a couple of hundred confirmations is a significant communication > overhead, and has an impact on privacy. It doesn't have to be realtime, so onion routing/mix cascades would work fine. Already people are using BitCoin over Tor, or so I hear. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, Oct 28, 2011 at 10:32:19AM -0700, Morlock Elloi wrote: > Take a cheap Android, write the code you need for it, make it talk via USB, > rip out all antennas, put it in your box (wrap in a paper bag first), and > connect with USB cable to the internal USB port. > > HW cost: $80 Where do you get Huaweis for 80 USD? The cheapest I can get them is 99 EUR. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Sat, Oct 29, 2011 at 08:10:38PM +1100, ianG wrote: > Is there any particular reason why PCI(e) is preferred as a hardware > interface? Because that's the only thing server boards typically have. Plus, PCIe is much preferable to PCI in terms of throughput (not that makes a bottleneck for a crypto accelerator) and latency. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] New online class on Cryptography from Stanford, taught by Dan Boneh
http://www.crypto-class.org/ About The Course Cryptography is an indispensable tool for protecting information in computer systems. This course explains the inner workings of cryptographic primitives and how to correctly use them. Students will learn how to reason about the security of cryptographic constructions and how to apply this knowledge to real-world applications. The course begins with a detailed discussion of how two parties who have a shared secret key can communicate securely when a powerful adversary eavesdrops and tampers with traffic. We will examine many deployed protocols and analyze mistakes in existing systems. The second half of the course discusses public-key techniques that let two or more parties generate a shared secret key. We will cover the relevant number theory and discuss public-key encryption, digital signatures, and authentication protocols. Towards the end of the course we will cover more advanced topics such as zero-knowledge, distributed protocols such as secure auctions, and a number of privacy mechanisms. Throughout the course students will be exposed to many exciting open problems in the field. The course will include written homeworks and programming labs. The course is self-contained, however it will be helpful to have a basic understanding of discrete probability theory. The Instructor Professor Dan Boneh heads the applied cryptography group at the Computer Science department at Stanford University. Professor Boneh's research focuses on applications of cryptography to computer security. His work includes cryptosystems with novel properties, web security, security for mobile devices, digital copyright protection, and cryptanalysis. He is the author of over a hundred publications in the field and a recipient of the Packard Award, the Alfred P. Sloan Award, and the RSA award in mathematics. Professor Boneh received his Ph.D from Princeton University and joined Stanford in 1997. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] trustable self-signed certs in a P2P environment (freedombox)
I presume many here are aware of the Eben Moglen-started FreedomBox initiative, which sets out to build a Debian distro for lplug computers and similar which will package many existing tools for the end result of an end-user owned and operated, anonymizing and censorship-resistant infrastructure. One of the problems I did not see well-addressed yet is infrastructure for a cert trust network, which uses social graph information (FreedomBox is supposed to package a P2P alternative to Facebook & Co) for cert fingerprint validation. Is anyone aware of existing code which caches SSL cert fingerprints and alerts when one suddenly changes, informing of a potential MITM in progress? Thanks. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Crypto Advocacy TED Talk
- Forwarded message from Gregory Maxwell - From: Gregory Maxwell Date: Thu, 1 Dec 2011 01:38:33 -0500 To: Jeffrey Burdges Cc: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Crypto Advocacy TED Talk On Thu, Dec 1, 2011 at 12:01 AM, Jeffrey Burdges wrote: [snip] > Aside from arguing these point, there should be emphasis that "this ain't > your daddy's PGP", meaning modern crypto packages have grown incredibly easy > to use. Tor Browser Bundles are about the most user friendly thing in the > world. Off-the-record messaging is almost a triviality in Adium, Jitsi, or > other open source IM clients. Most mail readers have user friendly plugins > for GPG. etc. I've argued before that protocol designers have an ethical obligation to include always-on-by-default cryptography whenever it isn't contraindicated by other requirements— The primary idea being here that the whole cost of cryptography to the user can be drastically reduced when its properly integrated. In particular, even unauthenticated cryptography provides absolute immunity to passive attacks, invisible wiretapping dragnets, and gives active attacks a serious risk of discovery. And this protection can be added to any realtime communication for _free_ and invisibly from the users perspective. (Of course, authentication is important— and nothing unauthenticated should be advertised to the user as encrypted. But the unavoidable user-costlyness of authentication shouldn't prevent us from getting encryption). One point on this subject that is overlooked is the network effect: I may have good reasons why I should be using encryption, but it's very hard to use it when most of my friends are not using it. This is related to your point (1), but not identical. Unrelated to cover, my contacts can't use encryption with me if I don't use encryption— and asking me to use it is a social/time cost that discourages them from using it when they really should. Unless encryption is a norm they won't even ask. Related to your point (2) I'd add a more subtle argument: The widespread use of unencrypted communications enables an _industry_ of dragnet surveillance. Iran pays FooBarNetworks to build a fleet of passive eavesdropping widgets... The R&D cost gets sunk building it and then FooBar has a new product in their price book which their sales drones go peddling to everyone who will take them, including the governments of countries which are less prone to coming up with these initiatives on their own. In this manner, oppression gains a marketing department. Fairly modest decreases in the effectiveness of surveillance can break this cycle by making the initial cost less appealing and making the products harder to sell. (And at the extreme limit: A few billion to build and maintain an infrastructure of hundreds of thousands of optical taps and fast stateless packet filters is a _lot_ more attractive when it will intercept Almost Everything then when its mostly only useful for traffic analysis). Another point that I make when discussing this subject is that none of us is really able to correctly assess the risks in making the choice to use encryption: We're not aware of secret lawful and unlawful interception by governments (our own, and/or hostile ones) and organized crime. We don't have a good feel for how massive collections of data may be used against our interests in the future. And once disclosed the information genie can't easily be rebottled. Encryption is cheap insurance, and would be much cheaper if ubiquitously deployed. ___ liberationtech mailing list liberationt...@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] airgaps in CAs
Is anyone aware of a CA that actually maintains its signing secrets on secured, airgapped machines, with transfers batched and done purely by sneakernet? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin in endgame
On Thu, Feb 23, 2012 at 01:00:20AM -0800, Jonathan Thornburg wrote: > On Thu, 23 Feb 2012, James A. Donald wrote: > [[for attacking bitcoin]] > > botnets cannot compete with legit miners, because to get a reasonable > > return, > > you need to mine with a graphics card, and while mining with graphics card, > > your graphics goes to hell, which will cause the most slow witted owner of a > > zombie computer to do something. > > It's pretty easy for the botnet to monitor for human activity (e.g., > mouse movement, non-screensaver processes running) and suspend their > activity then. Since the computer is likely idle most of the time > (I'm assuming bonets mainly use home computers, which will be idle > when their owners are sleeping, and usually when owners are out > at school/work/shopping/etc in the daytime), the botnet throughput > is only modestly degraded. What is the actual problem with botnet blocks (which, so far I'm aware of, is a purely theoretical situation at this point)? Pecuniam non olet, after all. In general so far I fail to see the validity of most criticisms against BitCoin. So far I see the only real problem is government crackdown on exchanges, which only makes BTC free-floating and slows down the growth of the underlying economy. Sorry if this is off-topic to cryptography. We can take the thread offlist at any time. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [info] The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say)
(yay, Bamford is back from the dead) http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/1 The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say) By James Bamford March 15, 2012 | 7:24 pm | Categories: Crypto, Cybersecurity, Miscellaneous, NSA, Paranoia, privacy, Surveillance Photo: Name Withheld; Digital Manipulation: Jesse Lenz The spring air in the small, sand-dusted town has a soft haze to it, and clumps of green-gray sagebrush rustle in the breeze. Bluffdale sits in a bowl-shaped valley in the shadow of Utah’s Wasatch Range to the east and the Oquirrh Mountains to the west. It’s the heart of Mormon country, where religious pioneers first arrived more than 160 years ago. They came to escape the rest of the world, to understand the mysterious words sent down from their god as revealed on buried golden plates, and to practice what has become known as “the principle,” marriage to multiple wives. Today Bluffdale is home to one of the nation’s largest sects of polygamists, the Apostolic United Brethren, with upwards of 9,000 members. The brethren’s complex includes a chapel, a school, a sports field, and an archive. Membership has doubled since 1978—and the number of plural marriages has tripled—so the sect has recently been looking for ways to purchase more land and expand throughout the town. But new pioneers have quietly begun moving into the area, secretive outsiders who say little and keep to themselves. Like the pious polygamists, they are focused on deciphering cryptic messages that only they have the power to understand. Just off Beef Hollow Road, less than a mile from brethren headquarters, thousands of hard-hatted construction workers in sweat-soaked T-shirts are laying the groundwork for the newcomers’ own temple and archive, a massive complex so large that it necessitated expanding the town’s boundaries. Once built, it will be more than five times the size of the US Capitol. Rather than Bibles, prophets, and worshippers, this temple will be filled with servers, computer intelligence experts, and armed guards. And instead of listening for words flowing down from heaven, these newcomers will be secretly capturing, storing, and analyzing vast quantities of words and images hurtling through the world’s telecommunications networks. In the little town of Bluffdale, Big Love and Big Brother have become uneasy neighbors. The NSA has become the largest, most covert, and potentially most intrusive intelligence agency ever. Under construction by contractors with top-secret clearances, the blandly named Utah Data Center is being built for the National Security Agency. A project of immense secrecy, it is the final piece in a complex puzzle assembled over the past decade. Its purpose: to intercept, decipher, analyze, and store vast swaths of the world’s communications as they zap down from satellites and zip through the underground and undersea cables of international, foreign, and domestic networks. The heavily fortified $2 billion center should be up and running in September 2013. Flowing through its servers and routers and stored in near-bottomless databases will be all forms of communication, including the complete contents of private emails, cell phone calls, and Google searches, as well as all sorts of personal data trails—parking receipts, travel itineraries, bookstore purchases, and other digital “pocket litter.” It is, in some measure, the realization of the “total information awareness” program created during the first term of the Bush administration—an effort that was killed by Congress in 2003 after it caused an outcry over its potential for invading Americans’ privacy. But “this is more than just a data center,” says one senior intelligence official who until recently was involved with the program. The mammoth Bluffdale center will have another important and far more secret role that until now has gone unrevealed. It is also critical, he says, for breaking codes. And code-breaking is crucial, because much of the data that the center will handle—financial information, stock transactions, business deals, foreign military and diplomatic secrets, legal documents, confidential personal communications—will be heavily encrypted. According to another top official also involved with the program, the NSA made an enormous breakthrough several years ago in its ability to cryptanalyze, or break, unfathomably complex encryption systems employed by not only governments around the world but also many average computer users in the US. The upshot, according to this official: “Everybody’s a target; everybody with communication is a target.” For the NSA, overflowing with tens of billions of dollars in post-9/11 budget awards, the cryptanalysis breakthrough came at a time of explosive growth, in size as well as in power. Established as an arm of the Department of Defense following Pearl Harbor, with the primary purpose of preventing another surprise assault, the NSA suffe
Re: [cryptography] [tahoe-dev] pycryptopp benchmarks
- Forwarded message from Brian Warner - From: Brian Warner Date: Thu, 22 Mar 2012 12:09:40 -0700 To: tahoe-...@tahoe-lafs.org Subject: Re: [tahoe-dev] pycryptopp benchmarks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 Reply-To: Tahoe-LAFS development On 3/21/12 11:00 AM, Zooko Wilcox-O'Hearn wrote: > On 64-bit servers, the it costs something around 10 *nanoseconds* per > byte, and on François's little low-power ARM box, it costs about 200 > nanoseconds per byte. FYI, djb and friends just published a paper about high-speed crypto on ARM processors with the "NEON" vector instruction set (which includes the iPad 1 and iPhone 4), specifically the NaCl algorithms (Salsa20, Poly1305, Curve25519, and Ed25519). They got encryption down to 5.6 CPU cycles per byte. http://cr.yp.to/highspeed/neoncrypto-20120320.pdf cheers, -Brian ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] John Nash’s Letter to the NSA
http://agtb.wordpress.com/2012/02/17/john-nashs-letter-to-the-nsa/ John Nash’s Letter to the NSA February 17, 2012 by Noam Nisan The National Security Agency (NSA) has recently declassified an amazing letter that John Nash sent to it in 1955. It seems that around the year 1950 Nash tried to interest some US security organs (the NSA itself was only formally formed only in 1952) in an encryption machine of his design, but they did not seem to be interested. It is not clear whether some of his material was lost, whether they ignored him as a theoretical professor, or — who knows — used some of his stuff but did not tell him. In this hand-written letter sent by John Nash to the NSA in 1955, he tries to give a higher-level point of view supporting his design: In this letter I make some remarks on a general principle relevant to enciphering in general and to my machine in particular. He tries to make sure that he will be taken seriously: I hope my handwriting, etc. do not give the impression I am just a crank or circle-squarer. My position here is Assist. Prof. of Math. My best known work is in game theory (reprint sent separately). He then goes on to put forward an amazingly prescient analysis anticipating computational complexity theory as well as modern cryptography. In the letter, Nash takes a step beyond Shannon’s information-theoretic formalization of cryptography (without mentioning it) and proposes that security of encryption be based on computational hardness — this is exactly the transformation to modern cryptography made two decades later by the rest of the world (at least publicly…). He then goes on to explicitly focus on the distinction between polynomial time and exponential time computation, a crucial distinction which is the basis of computational complexity theory, but made only about a decade later by the rest of the world: So a logical way to classify enciphering processes is by t he way in which the computation length for the computation of the key increases with increasing length of the key. This is at best exponential and at worst probably at most a relatively small power of r, ar^2 or ar^3, as in substitution ciphers. He conjectures the security of a family of encryption schemes. While not totally specific here, in today’s words he is probably conjecturing that almost all cipher functions (from some — not totally clear — class) are one-way: Now my general conjecture is as follows: for almost all sufficiently complex types of enciphering, especially where the instructions given by different portions of the key interact complexly with each other in the determination of their ultimate effects on the enciphering, the mean key computation length increases exponentially with the length of the key, or in other words, the information content of the key. He is very well aware of the importance of this “conjecture” and that it implies an end to the game played between code-designers and code-breakers throughout history. Indeed, this is exactly the point of view of modern cryptography. The significance of this general conjecture, assuming its truth, is easy to see. It means that it is quite feasible to design ciphers that are effectively unbreakable. As ciphers become more sophisticated the game of cipher breaking by skilled teams, etc., should become a thing of the past. He is very well aware that this is a conjecture and that he cannot prove it. Surprisingly, for a mathematician, he does not even expect it to be solved. Even more surprisingly he seems quite comfortable designing his encryption system based on this unproven conjecture. This is quite eerily what modern cryptography does to this day: conjecture that some problem is computationally hard; not expect anyone to prove it; and yet base their cryptography on this unproven assumption. The nature of this conjecture is such that I cannot prove it, even for a special type of ciphers. Nor do I expect it to be proven. All in all, the letter anticipates computational complexity theory by a decade and modern cryptography by two decades. Not bad for someone whose “best known work is in game theory”. It is hard not to compare this letter to Goedel’s famous 1956 letter to von Neumann also anticipating complexity theory (but not cryptography). That both Nash and Goedel passed through Princeton may imply that these ideas were somehow “in the air” there. ht: this declassified letter seems to have been picked up by Ron Rivest who posted it on his course’s web-site, and was then blogged about (and G+ed) by Aaron Roth. Edit: Ron Rivest has implemented Nash’s cryptosystem in Python. I wonder whether modern cryptanalysis would be able to break it. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] can the German government read PGP and ssh traffic?
On Fri, May 25, 2012 at 11:19:33AM -0700, Jon Callas wrote: > My money would be on a combination of traffic analysis and targeted > malware. We know that the Germans have been pioneering using targeted malware > against Skype. Once you've done that, you can pick apart anything else. Just > a simple matter of coding. Unrelated, IIRC Microsoft changed the architecture of supernodes to allow for lawful interception with Skype. It would be interesting to see inasmuch an open source version of Skype would want to evade that infrastructure, while asserting interoperability with legacy users. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tahoe-dev] “On the limits of the use cases for authenticated encryption”
- Forwarded message from Zooko Wilcox-O'Hearn - From: Zooko Wilcox-O'Hearn Date: Wed, 11 Jul 2012 15:08:33 -0300 To: Tahoe-LAFS development Subject: Re: [tahoe-dev] “On the limits of the use cases for authenticated encryption” Reply-To: Tahoe-LAFS development I've been thinking about this more, including re-reading BenL's post to tahoe-dev. I was inspired by hearing that Tahoe-LAFS's use case had been discussed at the recent "Directions in Authenticated Ciphers" workshop: http://hyperelliptic.org/DIAC/ I've decided that I wasn't really on the right track to say "Authenticated Encryption is useless for Tahoe-LAFS use cases", and instead I should say "We need *public key* Authenticated Encryption instead of *symmetric key* Authenticated Encryption for Tahoe-LAFS use cases". • symmetric-key Authenticated Encryption = Message Authentication Code + cipher • "signcryption" = digital signature + public key encryption • Tahoe-LAFS mutable = digital signature + cipher • Tahoe-LAFS immutable = data identified by its secure hash + cipher Regards, Zooko ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Fwd: Re: zfs encryption
- Forwarded message from Richard Lowe - From: Richard Lowe Date: Sat, 21 Jul 2012 22:08:45 -0400 To: r...@gentoo.org, z...@lists.illumos.org Subject: Re: [zfs] Fwd: Re: zfs encryption Reply-To: z...@lists.illumos.org hg clone ssh://a...@hg.opensolaris.org//hg/zfs-crypto/gate -- Rich --- 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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Behind Intel's New Random-Number Generator
http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 Behind Intel's New Random-Number Generator The random-number generator uses digital circuits to stump the smartest hackers By Greg Taylor, George Cox / September 2011 Image: Carl DeTorres Imagine that it's 1995 and you're about to make your very first online purchase. You open your Netscape browser, sipping coffee as the home page slowly loads. You then navigate to Amazon.com, a new online bookstore your friend told you about. As you proceed to make your purchase and enter your payment information, the address your browser points to changes from one starting with "http" to one that begins with "https." That signals that your computer has established an encrypted connection with Amazon's server. This allows you to send credit card information to the server without worrying that an identity thief will intercept the transmission. Unfortunately, your first online transaction was doomed from the start: It will soon be discovered that the supposedly secure transfer protocol your browser just followed wasn't very secure after all. The problem was that the secret keys Netscape was using weren't random enough. They were strings of only 40 bits, meaning there were around a trillion possible number combinations. That may seem like a lot, but hackers were able to break these codes, even with mid-1990s computer speeds, in about 30 hours. The nominally random number Netscape used to form a secret key was based on just three values—time of day, process identification number, and parent-process identification number—all of them predictable. This allowed the attackers to reduce the number of keys that they needed to try, and to find the right one much sooner than Netscape had anticipated. image of lava lamp Photo: iStockphoto A Whole Lot of Lava Lavarand was developed in 1996 to generate randomness from lava lamps. Over a million people grabbed numbers from the Lavarand website. Netscape's programmers would have loved to use a completely random number to form the encryption key, but they had a hard time figuring out how to come up with one. That's because digital computers are always in well-defined states, which change only when the programs they are running tell them to change. The best you can often do with a computer is to simulate randomness, generating what are called pseudorandom numbers by using some sort of mathematical procedure. A set of such numbers may at first glance look perfectly random, but somebody else using the same procedure could easily generate exactly the same set of numbers, which often makes them a poor choice for encryption. Researchers have managed to devise pseudorandom-number generators that are considered cryptographically secure. But you must still start them off using a special seed value; otherwise, they'll always generate the same list of numbers. And for that seed, you really want something that's impossible to predict. Fortunately, it's not hard to harvest truly unpredictable randomness by tapping the chaotic universe that surrounds a computer's orderly, deterministic world of 1s and 0s. But how exactly do you do that? For several years, you could find an online source of random numbers, called Lavarand. It got its numbers from the pictures a computer took of the waxy blobs churning away inside lava lamps. More sophisticated hardware-based systems use quantum-mechanical phenomena, such as photons striking a half-silvered mirror, as a basis for generating random numbers. You can even get an ordinary unassisted computer to produce random numbers based on erratic events taking place within its own mundane hardware—the precise timing of keystrokes, for example. But to get many of these numbers, you'd need to hammer away at a lot of keys. We and our colleagues at Intel think this should be easier. That's why for more than a decade now, many of our company's chip sets have included an analog, hardware-based random-number generator. The problem is that its analog circuitry squanders power. Also, it's hard to keep that analog circuitry working properly as we improve our fabrication processes. That's why we have now developed a new and entirely digital system that allows a microprocessor to produce a copious stream of random values without those difficulties. Soon it will be coming to a processor near you. chart, uncertain circuits UNCERTAIN CIRCUITS: When transistor 1 and transistor 2 are switched on, a coupled pair of inverters force Node A and Node B into the same state [left]. When the clock pulse rises [yellow, right], these transistors are turned off. Initially the output of both inverters falls into an indeterminate state, but random thermal noise within the inverters soon jostles one node into the logical 1 state and the other goes to logical 0. Click on image for enlargement. Intel's first attempt to help an average computer produce better random numbers came in 1999, when the comp
[cryptography] [tahoe-dev] Tahoe-LAFS Weekly Conference Call summary 2012-08-07
6# Add combined AES+XSalsa20 cipher module https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1679# Nondeterministic NoSharesError for direct CHK download in 1.8.3 and 1.9.1 ¹ https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Bibliography#CipherCombiners tickets mentioned in this letter: https://tahoe-lafs.org/trac/pycryptopp/ticket/46# Add combined AES+XSalsa20 cipher module ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [zfs] SHA-3 winner announced
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Wed, 03 Oct 2012 08:22:26 +0200 To: "" Subject: [zfs] SHA-3 winner announced User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Reply-To: z...@lists.illumos.org Hi All, As many of you are probably aware, NIST has just announced the SHA-3 winner: Keccak. Wonderful, so now we can go ahead and implement it in ZFS as the next-gen hash algo for dedup, right? Sadly, no. As I predicted, NIST could, and it seems did, choose a candidate that fits their criteria, not ours. Keccak, you see, is slow. Mighty slow. It's comparable to and at times even slower than the current SHA-2. See: http://bench.cr.yp.to/graph-sha3/1536-thumb.png Of course, I already hear people object: "But, it'll become faster once we get hardware implementations!" Sadly, no. Here are a few reasons why the "HW FTW!" argument is invalid: 1) x86 currently lacks even an implementation of SHA-2, which is over a decade old, so I do not expect SHA-3 to come along any time soon. 2) The UltraSPARC T2 and higher are currently the only CPUs capable of running Illumos that also have the algo in hardware and they got the capability after 6 years from the release of the algorithm (and Illumos doesn't even support that, but that's another story). Even considering an optimistically fast design cycle, I don't expect SHA-3 to appear in SPARC before the T6 (considering the T5 is slated for release pretty soon, so feature additions to the silicon are currently highly unlikely), which is on track for release in 2013/2014. My personal guess is that it's more likely to appear in the next release cycle after the T6, some time in 2014 or 2015. 3) Illumos runs on a wide variety of platforms, most of which will probably never get SHA-3 in hardware for the foreseeable future. I know I'm going to get a lot of flack for saying so, but the hard reality is that SHA-3 is over and that they've chosen an algorithm that's essentially useless to ZFS. Sure it has a nice security margin, much better than SHA-2, but we were already happy with the security margin we had before, so what we wanted next is more speed, and sadly, that's not something Keccak improves on. In conclusion, I'd like to propose a course of action: mainline one (or multiple) of the algorithms which I submitted patches for: Edon-R, BMW or Skein. All of them have a security margin that's better than SHA-2 and much, much better performance. Cheers, -- Saso --- 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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] SHA-3 winner announced
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Wed, 03 Oct 2012 15:39:39 +0200 To: z...@lists.illumos.org CC: Eugen Leitl Subject: Re: [cryptography] [zfs] SHA-3 winner announced User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Well, it's somewhat difficult to respond to cross-posted e-mails, but here goes: On 10/03/2012 03:15 PM, Eugen Leitl wrote: > - Forwarded message from Adam Back - > > From: Adam Back > Date: Wed, 3 Oct 2012 13:25:06 +0100 > To: Eugen Leitl > Cc: cryptography@randombit.net, Adam Back > Subject: Re: [cryptography] [zfs] SHA-3 winner announced > User-Agent: Mutt/1.5.21 (2010-09-15) > > (comment to Saso's email forwarded by Eugen): > > Well I think it would be fairer to say SHA-3 was initiatied more in the > direction of improving on the state of art in security of hash algorithms > [snip] > In that you see the selection of Keecak, focusing more on its high security > margin, and new defenses against existing known types of attacks. At no point did I claim that the NIST people chose badly. I always said that NIST's requirements need not align perfectly with ZFS' requirements. > If the price of that is slower, so be it - while fast primitives are very > useful, having things like MD5 full break and SHA-1 significant weakening > take the security protocols industry by surprise is also highly undesirable > and expensive to fix. To some extent for the short/mid term almost > unfixable given the state of software update, and firmware update realities. Except in ZFS, where it's a simple zfs set command. Remember, Illumos' ZFS doesn't use the hash as a security feature at all - that property is not the prime focus. > So while I am someone who pays attention to protocol, algorithm and > implementation efficiency, I am happy with Keecak. ZFS is not a security protocol, therefore the security margin of the hash is next to irrelevant. Now that is not to say that it's entirely pointless - it's good to have some security there, just for the added peace of mind, but it's crazy to focus on it as primary concern. > And CPUs are geting > faster all the time, the Q3 2013 ivybridge (22nm) intel i7 next year is > going to be available in 12-core (24 hyperthreads) with 30GB cache. Just > chuck another core at if if you have problems. ARMs are also coming out in > more cores. Aaah, the good old "but CPUs are getting faster every day!" argument. So should people hold off for a few years before purchasing new equipment for problems they have now? And if these new super-duper CPUs are so much higher performing, why not use a more efficient algo and push even higher numbers with them? If I could halve my costs by simply switching to a faster algorithm, I'd do it in a heartbeat! > And AMD 7970 GPU has 2048 cores. Are you suggesting we run ZFS kernel code on GPUs? How about driver issues? Or simultaneous use by graphical apps/games? Who's going to implement and maintain this? It's easy to propose theoretical models, but unless you plan to invest the energy in this, it'll most likely remain purely theoretical. > For embedded and portable > use, a reasonably fast and energy frugal 32-bit or 64-bit processor is > really cheap these days. OK I know there's always a market for 8-bit > processors, on the extreme cheap/low power end, but the validity of the cost > complaint is diminishing even there. My point in recommending a higher-speed hash is not for low-power systems - these wouldn't even come near dedup for the foreseeable future. Cheers, -- Saso - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] SHA-3 winner announced
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Wed, 03 Oct 2012 15:41:47 +0200 To: z...@lists.illumos.org CC: Eugen Leitl Subject: Re: [cryptography] [zfs] SHA-3 winner announced User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 On 10/03/2012 03:16 PM, Eugen Leitl wrote: > - Forwarded message from CodesInChaos - > > From: CodesInChaos > Date: Wed, 3 Oct 2012 14:38:43 +0200 > To: cryptography@randombit.net > Subject: Re: [cryptography] [zfs] SHA-3 winner announced > >> In that you see the selection of Keccak, focusing more on its high security >> margin, and new defenses against existing known types of attacks. > Is the margin really larger than the margin of Skein or Blake? The reasoning of NIST can be found here: http://www.nist.gov/itl/csd/sha-100212.cfm Quote: "The clarity of Keccak’s construction lends itself to easy analysis (during the competition all submitted algorithms were made available for public examination and criticism), and Keccak has higher performance in hardware implementations than SHA-2 or any of the other finalists." Cheers, -- Saso - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] SHA-3 winner announced
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Wed, 03 Oct 2012 15:54:08 +0200 To: z...@lists.illumos.org CC: Eugen Leitl Subject: Re: [cryptography] [zfs] SHA-3 winner announced User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 On 10/03/2012 03:16 PM, Eugen Leitl wrote: > - Forwarded message from "David McGrew (mcgrew)" - > > From: "David McGrew (mcgrew)" > Date: Wed, 3 Oct 2012 12:41:26 + > To: Eugen Leitl , > "cryptography@randombit.net" > Subject: Re: [cryptography] [zfs] SHA-3 winner announced > user-agent: Microsoft-MacOutlook/14.2.1.120420 > > If the hash function is being used in a symmetric message authentication > code, such as HMAC, then a good alternative would be to use a MAC that has > the performance properties that you are looking for, such as AES-GMAC, > which is supported on recent x86 systems > <http://www.intel.com/content/www/us/en/communications/communications-ia-ga > lois-counter-mode-paper.html>. Nope, ZFS doesn't use the checksum/hash algorithm as a HMAC. > AES-GCM is described as being supported > in ZFS in Solaris 11 at > <http://docs.oracle.com/cd/E23824_01/html/E24456/securedata-1.html#zfsencry > pt-1>, though I don't see any details as to how that is implemented. 1) Illumos != Solaris (the latter being a proprietary product of Oracle) 2) It's probably implemented in the crypto module in the Solaris kernel Anyways, this is irrelevant, since Illumos' ZFS doesn't use HMACs. > Are the requirements for the security of ZFS and the use of cryptography > in that filesystem documented anywhere? The checksum/hash algorithms are used primarily in two areas: 1) data integrity checksums (no security required) 2) in-line data deduplication (some security required) The latter is the only one that warrants some security concerns, in order to prevent an attacker generating a collision block to intentionally corrupt on-disk data, however, this attack is in itself highly impractical, even if the hash used were completely and utterly broken. And even so, it's very easy to tell ZFS to do bit-by-bit comparison of the target blocks prior to deduplication, instantly negating any potential security problems observed in the hash at a later date during its life cycle. > <https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data> mentions a > Merkle tree of checksums, where the checksum function can be either > Fletcher or SHA-256. A collision-resistant hash of an entire system is > indispensable if asymmetric authentication is needed, but are there common > scenarios where that is needed? If encryption is used in ZFS, then there > is necessarily a symmetric encryption key that is being managed; why not > use symmetric message authentication as well, and take advantage of the > performance gain? Illumos' ZFS (i.e. the open-source kind) doesn't have encryption. Oracle's ZFS uses SHA-256 if encryption is enabled and it's very easy to use that in Illumos as well, should encryption become available at some point in the future. This comes back to my earlier argument, that ZFS isn't a security protocol that's set in stone, but rather a dynamic filesystem that can cope with structural changes on the fly. Cheers, -- Saso - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Wed, 03 Oct 2012 22:19:19 +0200 To: Dr Adam Back CC: Eugen Leitl , cryptography@randombit.net Subject: Re: ZFS dedup? hashes (Re: [cryptography] [zfs] SHA-3 winner announced) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 On 10/03/2012 04:19 PM, Dr Adam Back wrote: > I infer from your comments that you are focusing on the ZFS use of a hash > for dedup? (The forward did not include the full context). Correct, though not complete. ZFS uses the hash also for data integrity. > A forged > collision for dedup can translate into a DoS (deletion) so 2nd pre-image > collision resistance would still be important. > > However 2nd pre-image collision resistance is typically offered at higher > assurance than chosen pairs of collisions (because you can use birthday > effect to roughly square root the search space with pairs). So to that > extent I agree your security reliance on hash properties is weaker than for > integrity protection. And SHA1 is still secure against 2nd pre-image > whereas its collision resistance has been demonstrated being below design > strength. Due to the design of ZFS, it's fairly hard to pull off a successful collision even if one has a hash function that's widely broken. Also, the mitigation to this kind of problem is fairly simple: turn on data verification (many dedup deployments already use this). So while this clearly doesn't amount to a good analysis, by my estimates, this attack is highly improbable. > Incidentally a somewhat related problem with dedup (probably more in cloud > storage than local dedup of storage) is that the dedup function itself can > lead to the "confirmation" or even "decryption" of documents with > sufficiently low entropy as the attacker can induce you to "store" or > directly query the dedup service looking for all possible documents. eg > say > a form letter where the only blanks to fill in are the name (known > suspected) and a figure (<1,000,000 possible values). This would require the user to be able to inject specific blocks into the dedup machinery and to have intimate knowledge of and access to the storage system anyway. > Also if there is encryption there are privacy and security leaks arising > from doing dedup based on plaintext. > > And if you are doing dedup on ciphertext (or the data is not encrypted), > you > could follow David's suggestion of HMAC-SHA1 or the various AES-MACs. In > fact I would suggest for encrypted data, you really NEED to base dedup on > MACs and NOT hashes or you leak and risk bruteforce "decryption" of > plaintext by hash brute-forcing the non-encrypted dedup tokens. As noted before, ZFS (in Illumos) currently doesn't support encryption. Oracle's implementation does and once you enable encryption, it automatically switches to HMAC-SHA256. If we get around to implementing encryption in Illumos, we would most likely go the same route. Thanks for your insights, though, they are certainly valuable. Cheers, -- Saso - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Jim Klimov - From: Jim Klimov Date: Thu, 04 Oct 2012 13:44:21 +0400 To: z...@lists.illumos.org CC: Eugen Leitl Subject: Re: ZFS dedup? hashes (Re: [cryptography] [zfs] SHA-3 winner announced) Reply-To: jimkli...@cos.ru Organization: JSC COS/HT User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 2012-10-03 18:52, Eugen Leitl wrote: > I infer from your comments that you are focusing on the ZFS use of a hash > for dedup? (The forward did not include the full context). A forged > collision for dedup can translate into a DoS (deletion) so 2nd pre-image > collision resistance would still be important. This subject was discussed a few months ago on zfs-discuss, I believe the thread history may be here: http://mail.opensolaris.org/pipermail/zfs-discuss/2012-July/051865.html Regarding the dedup-collision attacks, the problem is such: zfs dedup uses a checksum of a low-level block of ZFS data (which has passed compression, and encryption in case of Solaris 11). The final on-disk blocks with whatever contents are checksummed as part of ZFS integrity verification (lack of bitrot), and the stronger of these checksums can be used as keys into the deduplication table (DDT) if enabled for these datasets and used upon write (i.e. prepare the final block contents, make checksum, find it in DDT, increment the DDT entry counter or make a new DDT entry with counter=1). The DDT is shared by many datasets on the pool, and accounting of used/free space becomes "interesting", but the users have little if any ways to know whether their data was deduped (might infer that from changes of used/free space, but one can never be sure if HIS recently written file was involved). The block is several sectors in size, now ranging from 512b to 128Kb. In order to craft an attack on dedup you should: 1) Know what data will be written by the victim - exactly, including raw data, compression algo, encryption, etc.; 2) Create a block with forged data which has the same checksum (as used by this block's metadata on disk - currently sha256, maybe more as a result of Saso's work); 3) Be the very first writer into this pool that creates a block with this hash and enters it into the DDT. Reality is that any co-user of space on the deduped pool might do this. However, impracticality is that you need such intimate access to the victim's source data and system setup details, that you might just as well be the storage admin who can just corrupt and overwrite the victim's userdata block with whatever trash. Also, as far as dedup goes, a simple setting of verify=on requires comparison of on-disk block with the one ZFS is going to save (given they have same checksums, maybe size, and one is already in DDT), and if these two don't match ZFS should just write the new block non-deduped. The attack would at most waste space on the storage if the victim's data is indeed dedupable and ultimately many identical copies are saved, but the forged block only sits and occupies the DDT entry. > Incidentally a somewhat related problem with dedup (probably more in cloud > storage than local dedup of storage) is that the dedup function itself can > lead to the "confirmation" or even "decryption" of documents with > sufficiently low entropy as the attacker can induce you to "store" or > directly query the dedup service looking for all possible documents. eg say > a form letter where the only blanks to fill in are the name (known > suspected) and a figure (<1,000,000 possible values). What sort of attack do you suggest? That a storage user (attacker) pre-creates a million files of this form with filled-in data? Having no access to ZFS low-level internals and metadata, the end-user has no reliable way of knowing that a particular file got deduped. (And it's not files, but component blocks, to be exact). And if an admin does that, he might just as well read the victim's file directly (on non-encrypted pool). Or did I misunderstand your point? > Also if there is encryption there are privacy and security leaks arising > from doing dedup based on plaintext. > > And if you are doing dedup on ciphertext (or the data is not encrypted), you > could follow David's suggestion of HMAC-SHA1 or the various AES-MACs. In > fact I would suggest for encrypted data, you really NEED to base dedup on > MACs and NOT hashes or you leak and risk bruteforce "decryption" of > plaintext by hash brute-forcing the non-encrypted dedup tokens. I am not a cypher expert to even well decipher this part ;) HTH, //Jim Klimov - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.or
[cryptography] cjdns review
I've recently become interested in cjdns http://en.wikipedia.org/wiki/Cjdns which apparently used NaCl in UDP over tun when tunneling. I'm not aware of any review of the entire system, including key generation etc. Has this been done yet? Thanks. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Thu, 04 Oct 2012 15:19:59 +0200 To: z...@lists.illumos.org CC: Eugen Leitl Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Reply-To: z...@lists.illumos.org On 10/04/2012 02:41 PM, Eugen Leitl wrote: > - Forwarded message from "David McGrew (mcgrew)" - > > From: "David McGrew (mcgrew)" > Date: Thu, 4 Oct 2012 12:19:55 + > To: Eugen Leitl , > "cryptography@randombit.net" > Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner > announced) > user-agent: Microsoft-MacOutlook/14.2.1.120420 > > It would be redundant to use HMAC-SHA256 in conjunction with authenticated > encryption modes like those mentioned on the Oracle webpage that I > mentioned (AES-GCM and AES-CCM).Perhaps what you meant to say is that > when those modes are used, that SHA256 is used as the ZFS data-integrity > checksum? Or is it the case that the data-integrity checksum can use a > keyed message authentication code? > >> If we get around to implementing >> encryption in Illumos, we would most likely go the same route. Thanks >> for your insights, though, they are certainly valuable. > > Is there any public specification for how cryptography is used in either > the Sun/Oracle version or the Illumos version of ZFS? I'm not really sure how Oracle implemented their stuff in detail. I know that they use the block-level checksum to also authenticate the data, but then they also say that you can perform a block validation even if you don't have the encryption key. Best talk to Oracle about the details on that. Illumos' ZFS doesn't have encryption, so block authentication isn't important for us. Cheers, -- Saso --- 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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Thu, 04 Oct 2012 15:39:18 +0200 To: z...@lists.illumos.org CC: Eugen Leitl Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 On 10/04/2012 02:41 PM, Eugen Leitl wrote: > - Forwarded message from Adam Back - > > From: Adam Back > Date: Thu, 4 Oct 2012 13:39:35 +0100 > To: Eugen Leitl > Cc: cryptography@randombit.net, Jim Klimov , > Adam Back > Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner > announced) > User-Agent: Mutt/1.5.21 (2010-09-15) > > On Thu, Oct 04, 2012 at 11:47:08AM +0200, Jim Klimov wrote: >>> [decrypting or confirming encrypted or ACLed documents via dedup] >>> eg say a form letter where the only blanks to fill in are the name (known >>> suspected) and a figure (<1,000,000 possible values). >> >> What sort of attack do you suggest? That a storage user (attacker) >> pre-creates a million files of this form with filled-in data? > > The otherway around - let the victim store their confidential but low > entropy file. Then the attacker writes all permutations, and does timing or > disk free stats or other side channel to tell which was the correct guess. Since block dedup happens at transaction group (txg) commit intervals (i.e. the blocks aren't dedup'ed in memory, but only at txg commit to stable storage), in order to get reliable results (from observing storage behavior) you'd need to probe an entirely unloaded system extremely slowly (a few blocks per txg interval at best). Needless to say this is extremely optimistic and is still highly impractical. Any kind of other chatter on system (other processes doing something) will crush any hopes of this kind of attack yielding any useful data. Moreover, dedup is typically used in large storage systems (NAS/SAN) where one rarely gets local access (most users access the system via some file-level sharing protocol, e.g. NFS, or block-level, such as iSCSI or FC), which cover the inner workings of the storage system with a thick and heavy protocol blanket. > Given that one can get a private key out of an RSA private key holding > server by being another unprivileged process, based on cache lines, timing > etc it seems to me likely you would be able to tell dedup. And maybe you > can dedup lots of times, eg create, delete, wait for space reclaim, write > again (to get better accuracy stats from having lots of timing samples.) As mentioned above, you'll be probably limited by txg commit intervals, making this attack highly impractical. Cheers, -- Saso - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Pawel Jakub Dawidek - From: Pawel Jakub Dawidek Date: Thu, 4 Oct 2012 16:00:05 +0200 To: z...@lists.illumos.org Cc: Eugen Leitl Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Oct 04, 2012 at 03:39:18PM +0200, Sašo Kiselkov wrote: > On 10/04/2012 02:41 PM, Eugen Leitl wrote: > > - Forwarded message from Adam Back - > > > > From: Adam Back > > Date: Thu, 4 Oct 2012 13:39:35 +0100 > > To: Eugen Leitl > > Cc: cryptography@randombit.net, Jim Klimov , > > Adam Back > > Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner > > announced) > > User-Agent: Mutt/1.5.21 (2010-09-15) > > > > On Thu, Oct 04, 2012 at 11:47:08AM +0200, Jim Klimov wrote: > >>> [decrypting or confirming encrypted or ACLed documents via dedup] > >>> eg say a form letter where the only blanks to fill in are the name (known > >>> suspected) and a figure (<1,000,000 possible values). > >> > >> What sort of attack do you suggest? That a storage user (attacker) > >> pre-creates a million files of this form with filled-in data? > > > > The otherway around - let the victim store their confidential but low > > entropy file. Then the attacker writes all permutations, and does timing or > > disk free stats or other side channel to tell which was the correct guess. > > Since block dedup happens at transaction group (txg) commit intervals > (i.e. the blocks aren't dedup'ed in memory, but only at txg commit to > stable storage), in order to get reliable results (from observing > storage behavior) you'd need to probe an entirely unloaded system > extremely slowly (a few blocks per txg interval at best). Needless to > say this is extremely optimistic and is still highly impractical. Any > kind of other chatter on system (other processes doing something) will > crush any hopes of this kind of attack yielding any useful data. > Moreover, dedup is typically used in large storage systems (NAS/SAN) > where one rarely gets local access (most users access the system via > some file-level sharing protocol, e.g. NFS, or block-level, such as > iSCSI or FC), which cover the inner workings of the storage system with > a thick and heavy protocol blanket. Invalidating one side channel doesn't mean there aren't more. It is safer to assume there are more. Another one that comes to my mind is to wait until the load is small and observe with df(1) if the used space grows when we write and by how much. You can even do binary search by writing many possible blocks and observing if the space grew as much as it should. If not, maybe we have a hit and we can split our blocks in half and retry, etc. This would work over NFS just fine. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Jim Klimov - From: Jim Klimov Date: Thu, 04 Oct 2012 19:12:16 +0400 To: z...@lists.illumos.org CC: Pawel Jakub Dawidek , Eugen Leitl Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) Reply-To: jimkli...@cos.ru Organization: JSC COS/HT User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 2012-10-04 18:00, Pawel Jakub Dawidek wrote: > Invalidating one side channel doesn't mean there aren't more. It is > safer to assume there are more. True. One security project I was affiliated with began with an axiom: "a networked system is considered broken into", and the project was about providing safe communications - necessarily without traditional networking gear/interfaces - between internal data-processing subnets and those required to face the evil internet and thus tainted and corrupted ;) > Another one that comes to my mind is to > wait until the load is small and observe with df(1) if the used space > grows when we write and by how much. You can even do binary search by > writing many possible blocks and observing if the space grew as much as > it should. If not, maybe we have a hit and we can split our blocks in > half and retry, etc. This would work over NFS just fine. IMHO "your" dataset's (NFS share's) used space should grow regardless of dedup in action. However, if your viewpoint includes the parent pool, something might be inferred indeed. But as Saso said, you need a quiet pool doing nothing else but your cracking task for the duration of TXG interval, which is unlikely already - more so on shared cloud storage. //Jim - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] CryptoParty Handbook
erFS, XFS, Ext3, etc.) * file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems * file systems that make snapshots, such as Network Appliance's NFS server * file systems that cache in temporary locations, such as NFS version 3 clients * compressed file systems In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount). The wipe man page says Journaling filesystems (such as Ext3 or ReiserFS) are now being used by default by most Linux distributions. No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system. Some people see this concern as hypothetical, but it's pretty easy to test with loopback mounting. I just made a 100 MB file, initialized it with zeroes, created an ext4 filesystem in it, and loopback mounted the filesystem. Then I created several very large text files with repeating, easy-to-recognize contents, and then deleted the files with shred -u. It was still possible to find a small number of copies of the text file contents in the underlying storage file afterward -- probably because of data journaling in ext4. The book spends several pages describing how to make GUI interfaces for wipe and shred under GNOME, remarks that wipe is "a little more secure" than shred, and doesn't mention that (according to their own official documentation) neither program can be assumed to work properly on a modern system! :-( Things like this make me worry that this book needs some more work. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] CryptoParty Handbook
- Forwarded message from Asher Wolf - From: Asher Wolf Date: Fri, 05 Oct 2012 13:26:09 +1000 To: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] CryptoParty Handbook User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Reply-To: liberationtech At the moment, public edit function on the crowd-sourced portal for the CryptoParty Handbook has been removed due to ongoing attempts at vandalism of the document. If you would like to contribute, make edits or alterations, please either email me at: asherw...@cryptoparty.org On 5/10/12 12:11 PM, Nick M. Daly wrote: > Andrew Mallis writes: > >> This 392 page, Creative Commons licensed handbook is designed to help >> those with no prior experience to protect their basic human right to >> Privacy in networked, digital domains... Most importantly however >> this handbook is intended as a reference for use during Crypto >> Parties. > > Andrew, this is great work. I started reading it on the bus today and > found a few bits that could be updated or clarified. The numbers are > page numbers. > > - [ ] 5: Remove the link to opensourceecology.org. > > - [ ] 7: "as many or as few as two people" - an incomplete thought. > > - [ ] 12: add the "you've got no business in my business" argument: > Privacy exists because part of the human experience is personal, > intimate, even. Robbing people of that devalues human life and > experience. > > - [ ] 21: give time values to password lengths and predictability. > e.g.: a completely random 8 character password provides up to 12 > hours of privacy after your password is exposed, if attacked by > one average blackhat [0]. Attacked by a script kitten? Maybe > longer, depending on the strength of their graphics card(s). > Attacked by a nation-state? It's probably seconds. > > - [ ] 22: add grc.com/passwords as a link for fully random passwords. > > - [ ] 25: Lower threatenable area: consider POP3 for your email to move > it off the easily accessible servers as quickly as possible. If > it's inconvenient for you, it'll be even more so for your > attackers. > > Is there a preferred contribution method? I didn't see one mentioned in > the PDF, but I probably missed it. > > Nick > > 0: http://arstechnica.com/security/2012/08/passwords-under-assault/ > > > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech > -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] cjdns review
On Fri, Oct 05, 2012 at 10:58:40AM +0200, Guus Sliepen wrote: > > 1. Measure. Don't speculate. > > I found a benchmark here: > https://github.com/cjdelisle/cjdns/blob/master/rfcs/benchmark.txt > > So it seems that is not as slow as I suspected: it can forward packets at a > rate of 7 Gbit/s on an Opteron 6128. So for a VPN or overlay network that is > OK. But for their intended goal of being able to work completely independent > of, and a replacement for, an existing Internet, it does require an awful lot > of CPU power on routers. Current routers have memory lookups on expensive (CAM) route memory, so if the logic is easy enough to cast into ASIC (or even an FPGA) the resulting packet forwarding rate might be actually quite impressive for amount of silicon and power footprint. > > 4. Perhaps most importantly, the public-key computation (Curve25519) is > > reusable (see crypto_box_afternm()) whenever the sender-receiver set is > > the same. This means that specifying crypto_box() for every packet does > > _not_ imply public-key cryptography for every packet. > > I did not know of this feature; and delving into the source code of cjdns, > crypto_box_afternm() is indeed what is being used. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-dev] Even more notes on relay-crypto constructions
ous implementations have timing attacks due to table > lookups [DJB-Timing]. OpenSSL has three fast x86 implementations: one > of them uses vector permutations, one uses bit-slicing, and one uses > the aesni instructions to invoke the chip's built-in AES capabilities. > On high-end Intel chips, these take about 12-25, 7-9, and 1.5 cycles > per byte respectively. The bitsliced one really needs to encrypt 4KiB > at a time (yes, kibibytes), which makes it fine for counter mode but > not so good for CBC. (Those numbers are from the OpenSSL source.) > Key setup times are cheap for all of these (I think!), but the > bitsliced implementation gets expensive if you change the key (or > the stream position). > > > Salsa20 (and its descendant, ChaCha) is the Obvious Second Choice for > people who don't want to use AES. It is faster than AES on every > platform except those with hardware support for AES; 4-7 cycles per > byte seems typical for high-end Intel stuff. You would probably have > to go out of your way to implement it in a way that was vulnerable to > timing side-channel attacks. The only arguments for its insecurity > that I'm aware of are that although it has fewer known flaws than AES, > it has received less attention than AES, therefore is likelier to > _unsuspected_ problems. The counterargument there is that there _are_ > several dozen cryptographers who have tried to attack it (or attack > reduced-round variants of it), several of whom have also done > successful results against AES. [DJB-Comm] Per-key setup time is > basically nonexistent. Per-key setup time consists of one vector addition (of the first half of the key into the constants). (DJB's timing reports in http://cr.yp.to/papers.html#chacha repeat this operation for each block, but I would rather do it once per key if at all possible.) > There are a lot of constructions out there that want to do > multiplication in GF(2^128) as a basic operation. That turns out to > be less than totally straightforward, though. On newer intel chips, > you've got a "multiply without carry" instruction that can supposedly > let you get to around 2 cycles per byte. On other platforms, you're > reduced to worse trickery to try to get good performance without > timing side-channels, for an amount of trickery dependent on what > operation you're trying to do exactly. > > The easiest GF(2^128) operation to implement safely and quickly is > multiplication by a known compile-time value. (It's easy enough that > even I could do it.) Next easiest is multiply a large number of > values by the same run-time-fixed value -- you do precomputation on > the value in order to generate some tables. (The scary, fast variants > use big tables; the still-a-little-scary variants use 256-byte tables, > and get performance on high-end Intel boxes around 7-10 cycles per > byte when doing GCM.) Full-on multiplication of two arbitrary > GF(2^128) values is slowest still. The obvious way to implement GF(2^128) multiplication of a large number of secret inputs y by one learned-at-runtime secret c is: * Compute a table of c*X^i for i = 0, ..., 127. (This table takes 128*128 bits, or 2048 bytes. Multiplication by X is easy and tolerably fast.) * For each input y (= y_0*X^0 + ... + y_127*X^127, with the y_i in GF(2)), compute y_0*(c*X^0) + ... + y_127*(c*X^127). (You've done this step for Pynchon Gate already; hopefully that runs in constant time.) > As a further wrinkle with GF(2^128), OpenSSL doesn't seem to actually > expose its "multiply in GF(2^128)" functions as far as I can tell: we > would need to snarf such code from elsewhere. > > > Oh! ARMv8 has an optional crypto instruction set that supports AES, > SHA256, and GF(2^128) multiplication [ARMv8]. If it looks like most > of the ARMs we care about are going to get it, that could factor into > our planning. I won't believe claims that AES hardware will be widely available until it actually is present in every new processor from a major manufacturer. Robert Ransom ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-dev] Even more notes on relay-crypto constructions
- Forwarded message from Robert Ransom - From: Robert Ransom Date: Tue, 9 Oct 2012 14:53:10 -0400 To: tor-...@lists.torproject.org Subject: Re: [tor-dev] Even more notes on relay-crypto constructions Reply-To: tor-...@lists.torproject.org On 10/9/12, Robert Ransom wrote: > On 10/8/12, Nick Mathewson wrote: >> The second category (frob, encrypt, frob) is pretty elegant IMO. The >> best-explained of these I've seen so far are in a >> paper by Palash Sarkar [Efficient-Tweakable], though the earlier TET >> construction [TET] might also be cool. For these, you need an >> invertible block-wise (Almost) (Xor-)Universal hash function, >> typically implemented with GF(2^128). I'm not sure if you could use a >> different field. > > Please actually *read* http://cr.yp.to/papers.html#securitywcs this > time (read the appendix first). If you use polynomial evaluation over > a different field, your ‘hash function’ will have small differential > properties with respect to addition *in that field*. The Poly1305 > paper then proves that the polynomial-evaluation part of Poly1305 also > has small differential properties with respect to addition in > Z/(2^128)Z . > > In short, you can use a different field for polynomial evaluation *if* > you also use a different addition operation. Sorry -- that paper does require polynomials over a field of the same size as a block cipher's block size (for AES, that means GF(2^128)), and does not work with general almost-(xor-)universal hash functions. > (If you're going to pass the result of the polynomial-evaluation > function through a one-way function so that you can tee off some bits > for a chaining output, you can use whatever addition operation you > want after the OWF.) I don't see a way to obtain a chaining output from iHCH or HOH. >> The multiplication operations here appear to be >> multiplication by a primitive element, and multiplication by a per-key >> element. The encryption step can be realized with a somewhat >> unorthodox counter-mode stream cipher, or a ciphertext-stealing ECB >> approach. I don't know what you'd need to do to substitute in an >> orthodox stream cipher for the one used in iHCH. Sarkar seems to see >> iHCH as a successor to HCH, which is a little worrisome given that HCH >> is a spiritual descendant of the patented XCB, but to me the two >> constructions (HCH, iHCH) look practically nothing alike except for >> their use of a counter mode step. iHCH and HOH use a block cipher, not just a stream cipher. Robert Ransom _______ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-dev] Even more notes on relay-crypto constructions
gt; tolerably fast.) > * For each input y (= y_0*X^0 + ... + y_127*X^127, with the y_i in > GF(2)), compute y_0*(c*X^0) + ... + y_127*(c*X^127). (You've done > this step for Pynchon Gate already; hopefully that runs in constant > time.) Hm. Did you figure out cycles-per-byte on that one? Back-of-the-envelope: Assuming 64-bit words, we're looking at a 128 instances of "get a bit from y," 128*2 instances of "Load the corresponding word from the table, then constant-time-conditionally-xor that word to the accumulator." The fast portable implementation of the conditional-xor I know, for a single bit in 'b', and a value in 'x' to be conditionally xored into 'a' is: "a ^= x & ~(b-1)". I *think* that's roughly 128 (and, sub, not) to get a mask for each bit, 128 shifts, then 256 loads, 256 ands (to apply the mask), and 256 xors. (Some of these operations are unnecessary; I am committing fencepost errors here. I'm also assuming all loads are one-cycle.) So that's about 1280 operations for 16 bytes of input to be multiplied by c, so that seems like something like 80 instructions per byte for a naive implementation. There are still probably more optimizations to be done, especially if we have wacky SIMD features to play with, or we can combine some of the operations above into single ones. Dynamic multiple issue and such CPU architectural tricks might get it down even more. Nevertheless, it still looks like it'd be expensive enough getting GF(2^128) right to make GF(2^128) unattractive. Still, maybe somebody should hack this up for the public good, whether we turn out to need GF(2^128) or not. >> As a further wrinkle with GF(2^128), OpenSSL doesn't seem to actually >> expose its "multiply in GF(2^128)" functions as far as I can tell: we >> would need to snarf such code from elsewhere. >> >> >> Oh! ARMv8 has an optional crypto instruction set that supports AES, >> SHA256, and GF(2^128) multiplication [ARMv8]. If it looks like most >> of the ARMs we care about are going to get it, that could factor into >> our planning. > > I won't believe claims that AES hardware will be widely available > until it actually is present in every new processor from a major > manufacturer. Agreed. -- Nick ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] best way to create entropy?
- Forwarded message from "Naslund, Steve" - From: "Naslund, Steve" Date: Thu, 11 Oct 2012 23:27:56 -0500 To: na...@nanog.org Subject: RE: best way to create entropy? I know that a popular method for generating random bit streams is to take radio (stellar) noise and convert it into a digital bit stream. Very popular among crypto geeks. Steven Naslund -Original Message- From: Dan White [mailto:dwh...@olp.net] Sent: Thursday, October 11, 2012 10:55 PM To: Jonathan Lassoff Cc: North American Network Operators Group Subject: Re: best way to create entropy? On 10/11/12 17:08 -0700, Jonathan Lassoff wrote: >On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson wrote: >> in the past, i've done many different things to create entropy - >> encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a >> kernel. but, what is best? just whatever gets your cpu to peak or are >> some tasks better than others? > >Personally, I've used and recommend this USB stick: >http://www.entropykey.co.uk/ > >Internally, it uses diodes that are reverse-biased just ever so close >to the breakdown voltage such that they randomly flip state back and >forth. +1. -- Dan White - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-dev] Even more notes on relay-crypto constructions
- Forwarded message from unknown - From: unknown Date: Thu, 11 Oct 2012 19:17:22 + To: tor-...@lists.torproject.org Subject: Re: [tor-dev] Even more notes on relay-crypto constructions Organization: PGPru.com X-Mailer: unknown User-Agent: unknown Reply-To: tor-...@lists.torproject.org On Tue, 9 Oct 2012 00:28:38 -0400 Nick Mathewson wrote: > So to be concrete, let me suggest a few modes of operation. I believe > I'm competent to implement these: I think (IMHO) Keccak makes many (most?) symmetric encryption modes obsolete in the near future. Now Keccak-Hash is SHA-3 winner. It is not only a hash. Keccak is universal and can be used to authenticated stream encryption with one pass with input any amount of pads and output any amount of additional MACs from one-pass operation (so called duplexing mode). http://sponge.noekeon.org/SpongeDuplex.pdf "Duplexing the sponge: single-pass authenticated encryption and other applications" Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. In this year Keccak will recieve only a hash status officialy. Later we can see many other modes of using Keccak as universal RO-indistinguishable PRF with good security proofs and tons of analysis published already. Some parts of protocols can be done more simply with Keccak: new padding modes for RSA instead of OAEP is one example. Cite: " In a sponge function, the input is like a white page: It does not impose any specific structure to it. Additional optional inputs (e.g., key, nonce, personalization data) can be appended or prepended to the input message according to a well-defined convention, possibly under the hood of diversification as proposed in [6, Section “Domain separation”]. K supports all the possible applications of sponge functions and duplex objects described in [6, Chapters “Sponge applications” and “Duplex applications”]. These include hash function, randomized hash function, hash function instance differentiation, slow one-way function, parallel and tree hashing, mask generating function, key derivation function, deterministic random bit generator, reseedable pseudo random bit sequence generator, message authentication code (MAC) function, stream cipher, random-access stream cipher and authenticated encryption. " http://keccak.noekeon.org/Keccak-submission-3.pdf "The Keccak SHA-3 submission" Guido Bertoni, Joan Daemen, Michael Peeters, Gilles Van Asshe Keccak is hardware fast and can be realased in GPU at first. "Keccak Tree hashing on GPU, using Nvidia Cuda API" https://sites.google.com/site/keccaktreegpu/ If NIST adopt many uses Keccak as standards then the most of cryptoinfrastructure migrate to it. Keccak in the future is more then AES today and makes many uses of AES (and any other blockciphers) unnecessary (excluding PRP-modes for disk encryption, but PRF-PRP transformation modes is potentially possible too). ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Your GPU's “Fingerprint” Could Lead to New Security Methods
http://h30565.www3.hp.com/t5/Feature-Articles/Your-GPU-s-Fingerprint-Could-Lead-to-New-Security-Methods/ba-p/8418 Your GPU's “Fingerprint” Could Lead to New Security Methods by Andy Patrizio (apatrizio) on 29-10-2012 08:00 AM starlight_dreamstimefree_141720.jpg In the online world, a World of Warcraft account can be worth serious money. With such an incentive, malware is set to steal your WoW login and password, should you become infected. To protect an account, WoW users have the option of purchasing an authenticator for a minor fee of $6.50. Of course, if you lose the authenticator or if it breaks, poof! goes your game access. Security veterans recognize this as two-factor authentication: a password and a separate, physical security device that the owner must have in their possession. While two-factor authentication can greatly increase your security, it also represents another point of vulnerability because you can always lose the device. Researchers in Europe have come up with an alternative. Instead, your computer's graphics processor unit (GPU) would be the authenticator, identifying a user by tying him to his specific GPU. The Physically Unclonable Functions Found in standard PC Components Project, or PUFFIN, say that every GPU has a unique and defining set of characteristics that make each GPU as unique and individual as a snowflake or a fingerprint. These differences are known as a physical unclonable functions (PUF); they can only be detected by software and by knowing where to look. This is how the PUFFIN group found the uniqueness to GPU memory in the first place, since it was looking for PUFs. The PUFFIN group, which specializes in cryptography, uses GPUs for number crunching, since these chips are essentially giant math co-processors. To get higher performance, the PUFFIN group designed an assembly language application and gained access to the static RAM on the GPU. One of the things they did was look at the contents of a GPU’s SRAM to see if the previous contents were still there, explained Dr. Tanja Lange, a professor in the department of Mathematics and Computer Science at Technische Universiteit Eindhoven, in Eindhoven, Holland. What they found looked promising for a PUF. To further investigate the behavior, they joined forces with two other universities, including the University of Chicago, and Intrinsic-ID, a Dutch company specializing in PUFs. The physical layout of SRAM cells is such that each of them falls to a 0 or 1 when unpowered, Dr. Lange explained. The choice depends on tiny manufacturing differences. When the SRAM is powered on, these values stay until drivers overwrite them with data. "Like fingerprints, the behavior of falling to 0 or to 1 is not perfectly deterministic, but we know how to deal with noisy data. It was known already that in general SRAM can be used to build PUFs," she said. What this means is the 0s and 1s of SRAM have a unique arrangement to each GPU – which enables your GPU to become your authenticator. A WoW gamer won't need the separate physical authenticator any more, as her GPU can handle authentication for them. Or, on the flip side, a GPU could be the validation that allows only a certain PC to access a certain resource. For example, C-level executives could have their own secured, private space on a corporate network which only they could access, with their PC's GPU acting as authentication. No other PC would be able to access that network space. The PUFFIN group managed to dig into the GPUs to read out the uninitialized memory. It could extract the information from Nvidia GPUs using Nvidia's CUDA language for programming the GPU processor. The researchers have not experimented with GPUs from AMD or Intel yet but they hope to find a similar scenario. "In principle, this should apply to anything out there," said Daniel J. Bernstein, a professor of computer science at the University of Illinois at Chicago and also a part-time professor at Technische Universiteit Eindhoven. "Whether we can get access from software is a new game for every processor. There's no reason things should be different for AMD and Intel. There should be the same variability in static RAM. Whether we can access it is another question." GPU makers don't want anyone looking at the initialization memory, so it took some effort on the part of the Eindhoven group to get at the memory. "Access [to the GPU SRAM] has to be integrated with OS kernel and hypervisor. There's still more steps to be taken. What we have now is a demo that GPUs have this identification information we can access and there are no clear obstacles to using it as security," said Bernstein. But he adds that it's not something that can be dropped into products today. "Based on what we've seen so far, it is impossible for anyone to clone the card," said Lange. "But turning identity into a full-fledged security mechanism is several steps we have to go through." Indeed, it will require an industry-wi
[cryptography] Quantum cryptography conquers noise problem
(ob caveat snake oil crypto) http://www.nature.com/news/quantum-cryptography-conquers-noise-problem-1.11849 Quantum cryptography conquers noise problem Encoded photons sent a record distance along busy optical fibres. Zeeya Merali 20 November 2012 Quantum cryptography could keep messages ultra-secure — if the right detector can be developed. N. Gregory/Alamy It’s hard to stand out from the crowd — particularly if you are a single photon in a sea of millions in an optical fibre. Because of that, ultra-secure quantum-encryption systems that encode signals into a series of single photons have so far been unable to piggyback on existing telecommunications lines. But now, physicists using a technique for detecting dim light signals have transmitted a quantum key along 90 kilometres of noisy optical fibre1. The feat could see quantum cryptography finally enter the mainstream. You cannot measure a quantum system without noticeably disrupting it. That means that two people can encode an encryption key — for bank transfers, for instance — into a series of photons and share it, safe in the knowledge that any eavesdropper will trip the system’s alarms. But such systems have not been able to transmit keys along telecommunications lines, because other data traffic swamps the encoded signal. As a result, quantum cryptography has had only niche applications, such as connecting offices to nearby back-up sites using expensive 'dark' fibres that carry no other signals. “This is really the bottleneck for quantum cryptography,” says physicist Nicolas Gisin, a scientific adviser at quantum-cryptography company ID Quantique in Geneva, Switzerland. Physicists have attempted to solve the problem by sending photons through a shared fibre along a 'quantum channel' at one characteristic wavelength. The trouble is that the fibre scatters light from the normal data traffic into that wavelength, polluting the quantum channel with stray photons. Andrew Shields, a physicist at the Toshiba Cambridge Research Laboratory, UK, and his colleagues have now developed a detector that picks out photons from this channel only if they strike it at a precise instant, calculated on the basis of when the encoded photons were sent. The team publishes its results in Physics Review X. Designing a detector with such a sharp time focus was tough, explains Shields. Standard detectors use semiconducting devices that create an avalanche of electrical charge when struck by a single photon. But it usually takes more than one nanosecond (10−9 seconds) for the avalanche to grow large enough to stand out against the detector’s internal electrical hiss — much longer than the narrow window of 100 picoseconds (10−10 seconds) needed to filter a single photon from a crowd. The team’s ‘self-differentiating’ detector activates for 100 picoseconds, every nanosecond. The weak charge triggered by a photon strike in this short interval would not normally stand out, but the detector measures the difference between the signal recorded during one operational cycle and the signal from the preceding cycle — when no matching photon was likely to be detected. This cancels out the background hum. Using this device, the team has transmitted a quantum key along a 90-kilometre fibre, which also carried noisy data at 1 billion bits per second in both directions — a rate typical of a telecommunications fibre. The team now intends to test the technique on a real telecommunications line. Gisin’s team has independently developed a photon detector with a similar time window, which they presented at the QCrypt 2012 meeting at the Centre for Quantum Technologies in Singapore in September. However, Gisin has calculated that such a technique cannot be used to transmit quantum signals beyond the range of a large city of 100 kilometres2. Scattering accumulates over distance, so there would eventually be so many stray photons that it would be impossible to filter them out, even with a precisely timed detector. Still, 90 kilometres is a “world record that is a big step forward in demonstrating the applicability of quantum cryptography in real-world telecommunications infrastructures”, says Vicente Martín, a physicist at the Technical University of Madrid. Nature doi:10.1038/nature.2012.11849 References Patel, K. A. et al. Phys. Rev. X 2, 041010 (2012). Article Show context Eraerds, P., Walenta, N., Legré, M., Gisin, N. & Zbinden, H. N. J. Phys. 12, 063027 (2010). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [tt] CryptX2: an Open Source Hardware Encrypted Storage Device
http://www.indiegogo.com/CryptX2 CryptX2: an Open Source Hardware Encrypted Storage Device The CryptX2 is a self contained hardware encrypted storage device designed with the highest level of security possible. $825 Raised of $18,750 Goal 17 days left Flexible Funding campaign Contribute Now ▶ This campaign will receive all of the funds contributed by Wed Dec 12 at 11:59PM PT. ___ tt mailing list t...@postbiota.org http://postbiota.org/mailman/listinfo/tt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Gmail and SSL
- Forwarded message from Randy - From: Randy Date: Fri, 14 Dec 2012 09:47:03 -0600 To: NANOG list Subject: Gmail and SSL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will "offer[s] a higher level of security to better protect your information". I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. Please google, remove this requirement. Source: http://support.google.com/mail/bin/answer.py?hl=en&answer=21291&ctx=gmail#strictSSL ----- End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Tue, 12 Feb 2013 23:14:36 +0100 To: z...@lists.illumos.org CC: Nico Williams , Richard Elling Subject: Re: [zfs] Edon-R hashing and dedup User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 Reply-To: z...@lists.illumos.org On 02/12/2013 10:31 PM, Nico Williams wrote: > On Tue, Feb 12, 2013 at 12:34 PM, Garrett D'Amore > wrote: >> I think security could be important here. A determined attacker with access >> to the file system (perhaps very indirectly) could cause devastating >> corruption if he could arrange for collisions against a key file or block on >> a dataset with dedup and no verify set. >> >> Admittedly the likelihood of a successful attack is low, but that isn't the >> same as saying that security is not a consideration for the ZFS hash >> function. > > That's why dedup requires a cryptographic hash. No, the cryptographic bit was chosen as a simple designator of "hash with collision resistance", since cryptographic security implies that. > Any SHA-3 candidate that was not rejected due to weaknesses discovered > in cryptanalysis is almost certainly good enough for dedup. I would contend that the priority for ZFS dedup is: 1) software speed 2) collision resistance 3) cryptographic security The last two are not the same. Other hashes I considered were: BLAKE2: 1) It's slower than Edon-R (considerably so, the best I managed to get was ~5 CPB). 2) The above result requires using SSE 4.1 or other advanced vector instructions, which is difficult to support in the kernel. This also means that performance will suffer significantly if these instructions aren't available (e.g. on older CPUs or non-x86 CPUs). 3) It's derived from BLAKE, one of the SHA-3 finalists, which should make it theoretically as safe (though it hasn't been subjected to cryptanalysis to make sure the implementors haven't made a mistake). Blue Midnight Wish: 1) It's somewhat slower than Edon-R (though not as slow as BLAKE2) 2) Has been subjected to SHA-3 cryptanalysis and currently no preimage attacks exist against it (and no practical attacks on the full version of the hash either). 3) Its implementation is pure C, like Edon-R (no SSE trickery required). Let's, however, not lose focus on what is really important. Edon-R has *not* been broken. 1st preimage at complexity 2^343 is at most a thinking pause, however, it is nowhere near being anything practical. We'd be using the hash truncated to 256-bits anyway, which makes an exhaustive search still much easier to perform. The reason SHA-3 discarded it is because SHA-3 has a much broader scope and is supposed to mandate a standard for hashing all sorts of data at all possible sensitivity levels. ZFS dedup has an extremely narrow scope and the nature of our data is much more constrained, meaning, even if some theoretical attack can be made remotely practical, it is still nowhere near to posing any problems for our particularly narrow-scoped application. Cheers, -- Saso --- 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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
writing it, will point at your cert > instead. I'm sorry, but these are just pure fantasy land. The attacks you describe are so unbelievably contrived that you might as well resort to rubber hose cryptanalysis and be done with: https://xkcd.com/538/ What you propose is akin to performing dental surgery through the anus. This is exactly the sort of discussion I was hoping to avoid: armchair experts making contriving up fantasies of attacks that can neither be quantitatively assessed nor approach by any rational means. Cheers, - -- Saso -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlEayasACgkQle4gLqwmJMfR+QCgn+1ohjckklfDbH24OYSXp4j8 KyAAn0Bi0fYKY03q+Q7d9+NAZB1MEwnY =1fHP -----END PGP SIGNATURE- --- 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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Cryptography super-group creates unbreakable encryption
- Forwarded message from "Fabio Pietrosanti (naif)" - From: "Fabio Pietrosanti (naif)" Date: Thu, 14 Feb 2013 02:03:26 +0100 To: liberationtech Subject: Re: [liberationtech] Cryptography super-group creates unbreakable encryption User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 Reply-To: liberationtech Here some notes i collected with a quick review of the source code: https://pad.riseup.net/p/silentcircle -naif On 2/14/13 1:36 AM, Nadim Kobeissi wrote: > This is good news! Still far from a complete source code release, but > it's good that they're progressing, even if very slowly. > > Once all of the code is out I'll finally shut up about Silent Circle. > > > NK > -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
- Forwarded message from Matthew Ahrens - From: Matthew Ahrens Date: Thu, 14 Feb 2013 13:32:35 -0800 To: z...@lists.illumos.org Subject: Re: [zfs] Edon-R hashing and dedup Reply-To: z...@lists.illumos.org On Mon, Feb 11, 2013 at 6:22 AM, Sašo Kiselkov wrote: > So I've been talking to some people around storage and found out that > SHA-256 hashing *is* a significant cost in implementing dedup. I know I'm arriving late to this discussion. For my own understanding, I'd like to attempt to summarize the various positions and get everyone's feedback. SHA-256 is slow; we'd like to find a faster algorithm to replace it, which will use less CPU. Such a replacement must be usable for dedup without verification. (Performance and behavior with verification is a secondary concern to the points outlined here.) Dedup inherently relies on probabilistic correctness: if there is a hash collision, incorrect data will be returned. This is true even with the best hash algorithms (including SHA-256), and even without the possibility of storing malicious data. However, the probability involved is exceedingly small. Given 2^64 bytes (16 exabytes) in 8KB blocks, the odds of a collision are approximately 1/2^155. This is less likely than consecutively buying 5 jackpot-winning lottery tickets (assuming lottery odds 1/100 million). Dedup is sometimes used with user-generated data (i.e. untrusted, possibly malicious users provide the data to store). In the case, the hash algorithm should be such that it is infeasible to find a block which hashes to a given value. Otherwise an untrusted user may cause ZFS to return incorrect data. Dedup is sometimes used only with trusted data (i.e. none of the data can be maliciously generated). In this case, the algorithm need only distribute input blocks evenly over all 2^256 possible hash values. It is OK if it is feasible to find a block with a given hash value, because the risk associated is no worse than the ideal case (e.g 1/2^155 chance of returning incorrect data with the workload described above). SHA-256 is currently used for both of these use cases (trusted and untrusted data). So a replacement should also be usable for both. Optionally, we could implement a third, even faster, algorithm for use only in the trusted case. Some people believe that this choice may be misused (i.e. used even when the data can not be trusted), and therefore this option should not be offered. I'm not an expert in crypto algorithms; I've only read the wikipedia page on the SHA-3 competition ( http://en.wikipedia.org/wiki/NIST_hash_function_competition). Being fairly paranoid mainly due to my lack of expertise in this area, I would prefer to choose one of the finalists as a replacement for SHA-256. It sounds like BLAKE and Skein have reasonable performance. I think that the easiest way forward will be to first agree on a high-performance replacement for SHA-256, which is usable in all cases that SHA-256 is, including with untrusted data. We can then evaluate demand for an even faster algorithm to be used only with trusted data. --matt --- 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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [FoRK] ELF .so encryption contract work, probably resulting in open source
- Forwarded message from "Stephen D. Williams" - From: "Stephen D. Williams" Date: Wed, 13 Mar 2013 19:43:06 -0700 To: Friends of Rohit Khare , fo...@lig.net, ge...@lig.net, Michael Tiemann , fosdwn...@lig.net Subject: [FoRK] ELF .so encryption contract work, probably resulting in open source User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 Reply-To: Friends of Rohit Khare We need the ability to encrypt the code in code segments of an ELF .so, for Linux / Android at least, with an AES key and also decrypt it in memory after loading by libdl using the same key. Key management is out of scope. Might want selective decryption/encryption. Signed code is in scope. Result will probably be releasable as open source. This is something that should already exist, we need it, and I can pay for it. If you know anyone interested, please connect us. I could do it in 1-3 weeks, but that's not going to happen anytime soon for a long todo list of reasons. Stephen -- Stephen D. Williams s...@lig.net stephendwilli...@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer ___ FoRK mailing list http://xent.com/mailman/listinfo/fork - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cypherpunks mailing list
On Mon, Mar 25, 2013 at 12:46:49AM -0700, Tony Arcieri wrote: > The original Cypherpunks mailing list seems dead. > > Is there any list that it's successor? De facto it's cypherpu...@al-qaeda.net ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cypherpunks mailing list
On Mon, Mar 25, 2013 at 05:50:18PM +0100, Adam Back wrote: >> Isn't exactly that a nice property of a "cypherpunks" list? > > No it is not, it is a way to persuade people to leave, or not join the > listserv. We have to agree to disagree on that one. A 'punk' of any kind will tend to thumb his nose at authorities. If they consider the name annoying, so much the better. >>> Maybe someone with a more neutral domain could try it - or a cypherpunks.* >>> domain if they have a listserv handy. >> >> "Cypherpunks is a distributed mailing list. A subscriber can subscribe >> to one node of the list and thereby participate on the full list. Each >> node (called a Cypherpunks Distributed Remailer [CDR], although they are >> not related to anonymous remailers) exchanges messages with the other >> nodes in addition to sending messages to its subscribers." > > Yes I know, but that badly named listserv is the last CDR. I find "the base" is a very good name for a listserv. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cypherpunks mailing list
On Mon, Mar 25, 2013 at 07:03:04PM +0100, Adam Back wrote: > But my point actually was b...@al-qaeda.net??? Come on that is watch list Of course it is pure watch list bait. That's the point. > bait and an invitation NOT to join list blah, whatever it is about. If you think it's a deterrent, then it's not the right list to join, anyway. I think I should be on any watch list known to man, if not, they've been asleep at the wheel. And it would be self-DoS, which is precisely the point. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Biggest Fake Conference in Computer Science
This is spam. I had to ban the guy from all my mailing lists. On Sat, Apr 20, 2013 at 10:25:22AM -0400, jimsimps...@hushmail.com wrote: > We are researchers from different parts of the world and conducted a study on > > the world’s biggest bogus computer science conference WORLDCOMP > ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia > from University of Georgia, USA. > > > We submitted a fake paper to WORLDCOMP 2011 and again (the > same paper with a modified title) to WORLDCOMP 2012. This paper > had numerous fundamental mistakes. Sample statements from > that paper include: > > (1). Binary logic is fuzzy logic and vice versa > (2). Pascal developed fuzzy logic > (3). Object oriented languages do not exhibit any polymorphism or inheritance > (4). TCP and IP are synonyms and are part of OSI model > (5). Distributed systems deal with only one computer > (6). Laptop is an example for a super computer > (7). Operating system is an example for computer hardware > > > Also, our paper did not express any conceptual meaning. However, it > was accepted both the times without any modifications (and without > any reviews) and we were invited to submit the final paper and a > payment of $500+ fee to present the paper. We decided to use the > fee for better purposes than making Prof. Hamid Arabnia (Chairman > of WORLDCOMP) rich. After that, we received few reminders from > WORLDCOMP to pay the fee but we never responded. > > > We MUST say that you should look at the above website if you have any > thoughts > to submit a paper to WORLDCOMP. DBLP and other indexing agencies > have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. > See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of > one of the > conferences of WORLDCOMP and notice that there is no listing after 2010. See > http://sites.google.com/site/dumpconf for comments from well-known > researchers > about WORLDCOMP. If WORLDCOMP is not fake then why did DBLP suddenly stopped > listing the proceedings after? > > > The status of your WORLDCOMP papers can be changed from “scientific” > to “other” (i.e., junk or non-technical) at any time. See the comments > http://www.mail-archive.com/tccc@lists.cs.columbia.edu/msg05168.html > of a respected researcher on this. Better not to have a paper than > having it in WORLDCOMP and spoil the resume and peace of mind forever! > > > Our study revealed that WORLDCOMP is a money making business, > using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing > out a small chunk of that money (around 20 dollars per paper published > in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) > who publicizes WORLDCOMP and also defends it at various forums, using > fake/anonymous names. The puppet uses fake names and defames other conferences > to divert traffic to WORLDCOMP. He also makes anonymous phone calls and > try to threaten the critiques of WORLDCOMP. That is, the puppet does all > his best to get a maximum number of papers published at WORLDCOMP to > get more money into his (and Prof. Hamid Arabnia’s) pockets. > > > Monte Carlo Resort (the venue of WORLDCOMP until 2012) has refused to > provide the venue for WORLDCOMP’13 because of the fears of their image > being tarnished due to WORLDCOMP’s fraudulent activities. WORLDCOMP’13 > will be held at a different resort. > > > WORLDCOMP will not be held after 2013. > > > The paper submission deadline for WORLDCOMP’13 was March 18 and it was > extended to April 6 and now it is extended to April 20 (it may be extended > again) but still there are no committee members, no reviewers, and there is > no > conference Chairman. The only contact details available on WORLDCOMP’s > website is just an email address! Prof. Hamid Arabnia expends the deadline > to get more papers (means, more registration fee into his pocket!). > > > Let us make a direct request to Prof. Hamid arabnia: publish all reviews for > all the papers (after blocking identifiable details) since 2000 conference. > Reveal the names and affiliations of all the reviewers (for each year) > and how many papers each reviewer had reviewed on average. We also request > him to look at the Open Challenge at https://sites.google.com/site/moneycomp1 > > > Sorry for posting to multiple lists. Spreading the word is the only way to > stop > this bogus conference. Please forward this message to other mailing lists and > people. > > > We are shocked with Prof. Hamid Arabnia and his puppet’s activities > http://worldcomp-fake-bogus.blogspot.com Search Google
Re: [cryptography] skype backdoor confirmation
On Fri, May 17, 2013 at 10:26:07AM +0300, ianG wrote: > Is it unreasonable for us to expect Skype to go another way? Are we > asking too much? It is unreasonable for an closed source product by a commercial vendor to go any other way. Fortunately, we have more or less useful open source/P2P alternatives which can be be forked if they start going sideways. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
On Thu, May 23, 2013 at 09:38:18AM +0200, David Adamson wrote: > Danilo Gligoroski wrote: > > > 1. Indeed these discussions among the security community > > 2. Eventually some contacts with journalists will help the cause (one live > > demonstration on some security/crypto conference like Usenix, Black Hat, > > Crypto, ... will do the job). > > 3. I see a chance for some other product like: Zfone (that never took > > significant popularity),maybe Pidgin, maybe Cryptocat, ... > > 4. Even some open source security plugin for Skype. > > My two cents: > 4a: A SSH Java open source wrapper around Skype will do the job. The > chat logs or any other traffic that Skype is leaking to some > Echelon-like spying sites will be externally encrypted by the SSH > wrapper. To move this thread a bit sideways, does anyone know whether Hangout claims to be end to end secure? Considering that Google is dropping XMPP support, I'm investigating other options, e.g. Jitsi. Has there been a security review for Jitsi? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] crypto breakage in SALT
Comments? https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] What project would you finance? [WAS: Potential funding for crypto-related projects]
On Sun, Jun 30, 2013 at 07:09:57PM -0700, Yosem Companys wrote: > Speaking of which... > > If you had an extra $2-3K to give to a liberationtech or crypto project, > who do you think would benefit the most? A BTNS implementation. There aren't any. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)
On Mon, Jul 01, 2013 at 01:31:51PM +0200, Guido Witmond wrote: > The only answer is to take key management out of the users' hands. And > do it automatically as part of the work flow. You need at least a Big Fat Warning when the new fingerprint differs from the cached one, and it's not just expired. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Google's QUIC
- Forwarded message from Saku Ytti - Date: Tue, 2 Jul 2013 21:35:58 +0300 From: Saku Ytti To: na...@nanog.org Subject: Re: Google's QUIC User-Agent: Mutt/1.5.21 (2010-09-15) On (2013-06-29 23:36 +0100), Tony Finch wrote: > Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to attribute as chance, considering both are DJB's work, both are used by his NaCl library and by extension by MinimaLT. Neither is particularly common algorithm. I'm not implying QUIC plagiarizes MinimaLT, there are differences in the protocol, just choice of the algorithm implies QUIC authors are aware of MinimaLT. -- ++ytti - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Crypto fails -- showcasing bad cryptography
http://www.cryptofails.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] Bitmessage needs an auditor
- Forwarded message from Chris Lentner - Date: Thu, 11 Jul 2013 21:22:10 -0400 From: Chris Lentner To: liberationt...@lists.stanford.edu Subject: [liberationtech] Bitmessage needs an auditor Reply-To: liberationtech I'm currently contributing to Bitmessage < https://bitmessage.org >. It's a p2p messaging network (think email, not IM) with built-in ECC, and it aims to hide sender & receiver. The network layer is fairly solid; right now we're mostly doing UI work. What we could really use is someone to spot the (inevitable) bugs in the crypto layer, but other input is very welcome as well. The code works out of the box (git clone && cd src && python bitmessagemain.py) on most linux distros. Thanks! -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - "The Beautiful & Secure Messenger"
- Forwarded message from Matt Mackall - Date: Thu, 11 Jul 2013 17:34:48 -0500 From: Matt Mackall To: liberationtech Subject: Re: [liberationtech] Heml.is - "The Beautiful & Secure Messenger" X-Mailer: Evolution 3.4.4-1 Reply-To: liberationtech On Thu, 2013-07-11 at 13:47 -0700, Andy Isaacson wrote: > > Linux now also uses a closed RdRand [2] RNG if available. > > There was a bunch of churn when this code went in, so I could be wrong, > but I believe that RdRand is only used to stir the same entropy pool as > all of the other inputs which are used to generate random data for > /dev/random et al. It's hard to leverage control of one input to a > random pool into anything useful. It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. >From a quick skim of current sources, much of that has recently been rolled back (/dev/random, notably) but kernel-internal entropy users like sequence numbers and address-space randomization appear to still be exposed to raw RdRand output. (And in the meantime, my distrust of Intel's crypto has moved from "standard professional paranoia" to "actual legitimate concern".) -- Mathematics is the supreme nostalgia of our time. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tahoe-dev] proposal: add padding
- Forwarded message from Zooko O'Whielacronx - Date: Fri, 12 Jul 2013 16:56:47 + From: Zooko O'Whielacronx To: Tahoe-LAFS development Subject: Re: [tahoe-dev] proposal: add padding Reply-To: Tahoe-LAFS development No, no, we rely on the correctness of our encryption to hide all information about the plaintext from an attacker who doesn't know the encryption key. Therefore, the pad bytes are all just zero bytes, and we believe that this pattern gives nothing useful to the cryptanalyst. (Our encryption is currently AES. I hope in the future to upgrade it to AES⊕XSalsa20 — see #1164 and wiki:OneHundredYearCryptography.) https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1164# use XSalsa20+AES-128 encryption https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography Regards, Zooko ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message ----- -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - "The Beautiful & Secure Messenger"
On Fri, Jul 12, 2013 at 10:29:49PM +0300, ianG wrote: > Not to mention, Intel have been in bed with the NSA for the longest > time. Secret areas on the chip, pop instructions, microcode and all > that ... A more interesting question is whether the non-USA > competitors are also similarly friendly. It seems there's a good niche for open hardware, either run in FPGAs (which are backdoorable, of course), or designs which can be verified optically, preferably using relatively large, "obsolete" structures. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] failure submission address now up at http://www.cryptofails.com/
In case you come across particular hair-raising crypto horrors, please submit them to the author listed on http://www.cryptofails.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - "The Beautiful & Secure Messenger"
On Sat, Jul 13, 2013 at 01:43:49AM -0400, Patrick Mylund Nielsen wrote: > Heh, might as well just give up. http://cm.bell-labs.com/who/ken/trust.html > > (I know what you meant, just couldn't resist.) Certainly a classic, but these days you can really bootstrap your toolchain in a cleanroom quite quickly. See e.g. http://www.excamera.com/sphinx/fpga-j1.html which is fundamentally not safe from attacks like http://www.h-online.com/security/news/item/Backdoor-found-in-popular-FPGA-chip-1585579.html but it's hard to see how you could get something in there in a tight, human-inspectable compilate, and use the FPGA as a sacrificial bootstrap step only. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] libfortuna fun
- Forwarded message from Waitman Gobble - Date: Wed, 17 Jul 2013 22:19:06 -0700 (PDT) From: Waitman Gobble To: liberationtech Subject: [liberationtech] libfortuna fun Reply-To: liberationtech Hi, I've been researching the Fortuna PRNG and found a good implementation within PostgreSQL. I ripped out a big chunk of the code in pgsql/contrib/pgcrypto and turned it into libfortuna. My first tests are positive, seems to work. I'm building on FreeBSD, but should work on other BSD/Unix systems. Maybe GNU/Linux, not sure, I tend to only build other people's projects on Linux. At the moment my test program dumps out 1024 fortuna-generated random numbers. But there's a whole swiss army knife of encryption related routines in pgcrypto, so it looks to be great fun to tinker with and expand the library, import the rest of the pgcrypto code base. I'm just getting started experimenting. Perhaps irrelevant, yet it seems like there's a good interest in encryption in this group, so I thought I'd share. The library code is at: https://github.com/waitman/libfortuna testing 123 programs at: https://github.com/waitman/fortuna-tests It's mostly unmodified PG code, replacing the PG memory management routines with 'native' jemalloc/malloc_np.h. When it seems sane I'll submit a FreeBSD port. Have fun, -- Waitman Gobble San Jose California USA +1.5108307875 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] Random number generator failure in Rasperri Pis?
- Forwarded message from KheOps - Date: Fri, 19 Jul 2013 14:03:23 +0200 From: KheOps To: "liberationt...@lists.stanford.edu" Subject: [liberationtech] Random number generator failure in Rasperri Pis? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 Reply-To: liberationtech Hi all, Just came accross this article, apparently showing the bad quality of the hardware RNG in Raspberri Pi devices. http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ Quite interesting since (pseudo-) random numbers are heavily used in crypto. Interesting also to see another post on this topic, after the study of a random number generation procedure formerly used in Cryptocat and that was also problematic. Datalove, KheOps -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] a Cypherpunks comeback
- Forwarded message from "Riad S. Wahby" - Date: Sat, 20 Jul 2013 12:41:25 -0400 From: "Riad S. Wahby" To: cpunks-recipients-suppres...@proton.jfet.org Subject: a Cypherpunks comeback User-Agent: Mutt/1.5.21 (2010-09-15) tl;dr: I'm writing to invite you back to the Cypherpunks mailing list. If you're interested, you can join via https://al-qaeda.net/mailman/listinfo/cypherpunks Hello, In the past couple days I've exchanged emails with John Young and Eugen Leitl on some brokenness in the Cypherpunks mailing list. This discussion brought us to a discussion of attempting to resurrect the list's wetware, as it were, in addition to its software. At Eugen's request, John dug up a couple Majordomo WHO outputs from about 15 years ago; I tidied up the lists, and now I'm writing to you. So! if you still have an interest in crypto, privacy, and politics, and if you want to discuss that interest with a bunch of like-minded weirdos from the aether, you can subscribe yourself via the web interface above or by sending an email with "subscribe" in the body to cypherpunks-requ...@al-qaeda.net. (I am aware the provocative choice of domain name may discourage you somewhat. I can only tell you that I've been running a Cypherpunks list of some sort from this domain for a bit over a decade, and I haven't yet been spirited away in a black helicopter. Here's hoping for another helicopter-free decade.) Best regards, and welcome back, preemptively, -=rsw on behalf of jya, eugen, and rsw - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] a Cypherpunks comeback
On Mon, Jul 22, 2013 at 09:41:14AM +0200, Adam Back wrote: > Could you please get another domain name, that name is just ridiculous. > > It might tickle your humour but I guarantee it does not 99% of potential > subscribers... > > Unless your hidden objective is to drive away potential subscribers. For those who dislike posting to the "The Base", here's an alternative domain for the same list: https://cpunks.org/mailman/options/cypherpunks > Adam > > On Sun, Jul 21, 2013 at 11:07:26AM +0200, Eugen Leitl wrote: > >- Forwarded message from "Riad S. Wahby" - > > > >Date: Sat, 20 Jul 2013 12:41:25 -0400 > >From: "Riad S. Wahby" > >To: cpunks-recipients-suppres...@proton.jfet.org > >Subject: a Cypherpunks comeback > >User-Agent: Mutt/1.5.21 (2010-09-15) > > > >tl;dr: > >I'm writing to invite you back to the Cypherpunks mailing list. If > >you're interested, you can join via > > https://al-qaeda.net/mailman/listinfo/cypherpunks > > > >Hello, > > > >In the past couple days I've exchanged emails with John Young and > >Eugen Leitl on some brokenness in the Cypherpunks mailing list. This > >discussion brought us to a discussion of attempting to resurrect the > >list's wetware, as it were, in addition to its software. At Eugen's > >request, John dug up a couple Majordomo WHO outputs from about 15 years > >ago; I tidied up the lists, and now I'm writing to you. > > > >So! if you still have an interest in crypto, privacy, and politics, and > >if you want to discuss that interest with a bunch of like-minded weirdos > >from the aether, you can subscribe yourself via the web interface above > >or by sending an email with "subscribe" in the body to > >cypherpunks-requ...@al-qaeda.net. > > > >(I am aware the provocative choice of domain name may discourage you > >somewhat. I can only tell you that I've been running a Cypherpunks list > >of some sort from this domain for a bit over a decade, and I haven't yet > >been spirited away in a black helicopter. Here's hoping for another > >helicopter-free decade.) > > > >Best regards, and welcome back, preemptively, > > > >-=rsw > >on behalf of jya, eugen, and rsw > > > >- End forwarded message - > >-- > >Eugen* Leitl http://leitl.org";>leitl http://leitl.org > >__ > >ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org > >AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 > >___ > >cryptography mailing list > >cryptography@randombit.net > >http://lists.randombit.net/mailman/listinfo/cryptography -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] ZeroReserve -- a friend 2 friend payment scheme and Bitcoin exchange
Implemented as a RetroShare plugin. https://github.com/zeroreserve/ZeroReserve ZeroReserve Friend 2 Friend Payment and Bitcoin exchange Prerequisite for building is a successful RetroShare build and sqlite3. To build, checkout the sources to the plugins directory of Retroshare and build with $ qmake && make clean && make To install on Windows, drop the resulting DLL into the %APPDATA%\Retroshare\extensions directory. To install on Linux, drop the resulting shared object into ~/.retroshare/extensions ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta
- Forwarded message from Mike Hearn - Date: Tue, 30 Jul 2013 14:12:51 +0200 From: Mike Hearn To: Wendell Cc: Bitcoin Dev , Gregory Maxwell , bitcoin-l...@lists.sourceforge.net Subject: Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta The TPM is a piece of secure* hardware that provides various cryptographic services to the host system. It is important to understand that it is not a crypto accelerator. It is a place to store keys and small pieces of data (like hashes, counters) where it's difficult for someone to extract them even if they have physical access. The TPM is designed to support trusted computing, a rather splendid set of extensions to the x86 architecture that let you do remote attestation, software sealing and other things. Or at least it would be splendid if it had been really finished off and pushed to completion by the designers. Unfortunately due to various political issues it exists in a quasi-finished, semi-broken state which only experts can use. Without a doubt you have never run any software in a TC environment. As part of that role, the TPM provides some permanent storage in the form of NVRAM. Because the TPM is designed to be as cheap as possible, it has a limited number of write cycles. Normally you're meant to store Intel TXT launch control policies and sealed keys there, but Pond uses it in a different way by storing keys there that it encrypts local data with. By erasing the key in the TPM chips memory area, the data on disk is effectively destroyed too. This is useful because modern "disks" are often SSD drives, or physical metal disks that use log structured file systems. Because flash memory has a limited number of write cycles per cell, internally SSDs have firmware that remap writes from logical addresses to different physical addresses, the goal is to avoid wearing down the drive and extend its useful life. Normally it doesn't matter, but if you want to delete data such that it's really really gone, it obviously poses a problem. Using TPM NVRAM solves it, albiet, at a high usability cost. *note: actual tamper resistance of real-world TPM chips is not something that seems to have been studied much On Tue, Jul 30, 2013 at 1:27 PM, Wendell wrote: > Can you explain this process for those of us not too familiar with TPM > chips? > > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote: > > > As a testament to the seriousness with which Pond takes forward > security, it can use the NVRAM in a TPM chip to reliably destroy keys for > data that an SSD device might have otherwise made un-erasable. > -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ bitcoin-list mailing list bitcoin-l...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [FoRK] Functional encryption, or "Computer scientists develop 'mathematical jigsaw puzzles' to encrypt software"
- Forwarded message from Noon Silk - Date: Wed, 31 Jul 2013 21:18:45 +1000 From: Noon Silk To: Friends of Rohit Khare Subject: [FoRK] Functional encryption, or "Computer scientists develop 'mathematical jigsaw puzzles' to encrypt software" Reply-To: Friends of Rohit Khare http://newsroom.ucla.edu/portal/ucla/ucla-computer-scientists-develop-247527.aspx Looks interesting. -- UCLA computer science professor Amit Sahai and a team of researchers have designed a system to encrypt software so that it only allows someone to use a program as intended while preventing any deciphering of the code behind it. This is known in computer science as "software obfuscation," and it is the first time it has been accomplished. [...] "You can inspect everything, you can turn it upside-down, you can look at it from different angles and you still won't have any idea what it's doing," he added. "The only thing you can do with it is put it together the way that it was meant to interlock. If you tried to do anything else — like if you tried to bash this piece and put it in some other way — you'd just end up with garbage." *Functional encryption* The new technique for software obfuscation paved the way for another breakthrough called functional encryption. With functional encryption, instead of sending an encrypted message, an encrypted function is sent in its place. This offers a much more secure way to protect information, Sahai said. Previous work on functional encryption was limited to supporting very few functions; the new work can handle any computable function. For example, a single message could be sent to a group of people in such a way that each receiver would obtain different information, depending on characteristics of that particular receiver. In another example, a hospital could share the outcomes of treatment with researchers without revealing details such as identifying patient information. "Through functional encryption, you only get the specific answer, you don't learn anything else," Sahai said. -- -- Noon Silk Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature." ___ FoRK mailing list http://xent.com/mailman/listinfo/fork - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Radiation Emission Controls
On Tue, Jul 30, 2013 at 03:18:51PM -0400, Riad S. Wahby wrote: > John Young wrote: > > Since nearly all government and commercial data centers > > have generator back-ups, how are emissions from generators > > controlled? > > On assumes that transient emissions, e.g., from a starter motor, follow > less stringent guidelines. And if the generators are diesel, they also > don't use spark plugs. > > This is also consistent with having some urea on site for treating > diesel exhaust. Is there any RF sigint at all done at the Utah site? It could all well be just a big crunch and storage facility. It would help if we had a good fiber map of the general area. I suspect that the NSA is doing a lot of decentral signal prefiltering and processing at the network edge, and only uses large central facilities if they're unavoidable. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Bitcoin-development] Preparing for the Cryptopocalypse
- Forwarded message from Gregory Maxwell - Date: Sun, 4 Aug 2013 23:41:57 -0700 From: Gregory Maxwell To: Peter Vessenes Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Preparing for the Cryptopocalypse On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes wrote: > I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He > told me recently NTRU, which is lattice based, is one of the few (only?) > NIST-recommended QC-resistant algorithms. Lamport signatures (and merkle tree variants that allow reuse) are simpler, faster, trivially implemented, and intuitively secure under both classical and quantum computation (plus unlikely some proposed QC strong techniques they're patent clear). They happen to be the only digital signature scheme that you really can successfully explain to grandma (even for values of grandma which are not cryptographers). They have poor space/bandwidth usage properties, which is one reason why Bitcoin doesn't use them today, but as far as I know the same is so for all post-QC schemes. > Though I question the validity of the claim that ECC is so much more secure > than RSA (with appropriate keysizes). The problems are intimately related, but under the best understanding ECC (with suitable parameters) ends up being the maximally hard case of that problem class. I do sometimes worry about breakthroughs that give index-calculus level performance for general elliptic curves, this still wouldn't leave it any weaker than RSA but ECC is typically used with smaller keys. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list bitcoin-developm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Wed, Aug 14, 2013 at 09:47:09AM +1000, James A. Donald wrote: > On 2013-08-14 6:10 AM, Nico Williams wrote: > > - it's really not easy to defeat the PRISMs. the problem is > >*political* more than technological. > > For a human to read all communications would be an impossible burden. We're rapidly approaching that point where judge, jury and executioner are completely automated. As such neither scaling issues of Stasi (at some point some half of the population were informants) nor quis custodiet are a problem. > Instead, apply the following algorithm. Identify people of > interest. Read communications between persons of interest. If > several people of interest talk to Bob, then Bob may well also a > person of interest. /Then/ read their communications. If > significant, add Bob to the list of people of interest. IIRC there's already collection on three degrees of separation in place, and that is already a fair fraction of the global population so at least part of the judging is already automated. > Looking at communication patterns, Identify the more central nodes > among people of interest. Make a special effort to crack the > communications of the most central nodes. > > The technological counter to this is the cypherpunks remailers, > which are unfortunately user hostile, especially when used with a > permanent identity. How badly bitrotted is the codebase? With the current threat model it looks like high-latency anonymous networks could well use a revival. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [tor-dev] Global semi-passive adversary: suggestion of using expanders
- Forwarded message from Paul-Olivier Dehaye - Date: Fri, 23 Aug 2013 03:08:59 +0200 From: Paul-Olivier Dehaye To: tor-...@lists.torproject.org Subject: [tor-dev] Global semi-passive adversary: suggestion of using expanders Reply-To: tor-...@lists.torproject.org Hello, Thank you for working on Tor. I have a suggestion and would appreciate input. Please bear with me as I have a limited understanding of the design of Tor and all the different threats that it is meant to mitigate. Below, a (?) indicates a place where I need some confirmation that my understanding is correct, and N indicates either the number of Tor nodes, the number of end-users, or the amount of traffic (I assume these are all linearly related). As far as I can tell, the main threat by a global passive adversary comes from traffic analysis (?). This attack should become easier as the number of Tor nodes increases (?): Tor uses a clique topology, so the number of edges potentially carrying traffic grows like N^2. A dual way to see this is that not enough mixing can happen around a node for incoming/outgoing edge pairs, bar injecting a huge amount of fake traffic. To compensate, it seems natural to look for a sparse yet highly mixing network topology. Mathematically, those are called expanders [1]. A typical example of a family of expanders would be the Erdos-Renyi model [2], and indeed I have found in the literature suggestions for basing anonymizing protocols on such a model. The analysis in the presence of an active adversary becomes very difficult though. Alternatively, one could use a different method for constructing that expander topology, working "all at once". This comes from recent mathematics research (<= 5 years, certainly not my own, see [3]). The graph is then a Cailey graph [4] in a matrix group (the group is fixed and determined by an approximation to the number of Tor nodes, such as nearest third power of a prime number). In some sense this construction interpolates between mixing chains and Tor, and can be seen as a lot of mixing chains interwoven. In the setting of Tor, constructing the Cailey graph would require making two distributed randomize choices: - a matching of elements of the group to Tor nodes (possibly 2:1 for some Tor nodes) - a small subset of generators for the Cailey graph >From my understanding of security protocols, it should be easy to do these two choices safely and fast, as it amounts to choosing a random element in S_N and filling lots of matrix entries with random elements between 1 and a prime p, with some rejection. Once that is done, the network topology is fully determined, and with very high probability gives an expander. This means that traffic gets mixed up in very few hops. The number of hops needed grows as log N, with a constant that can be mitigated by chosing a large generating set above. This is the only downside I see (apart from difficulty to explain the math behind this): the latency would increase, from 3 in the current protocol to maybe 10 or so. I don't know the details of the behaviour of the constants in the last paragraph, and would appreciate feedback from the list before looking too much into this. Paul Dehaye [1] http://en.wikipedia.org/wiki/Expander_graph [2] http://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93R%C3%A9nyi_model [3] http://terrytao.wordpress.com/2011/12/02/245b-notes-1-basic-theory-of-expander-graphs/Exercise 15 and remark below [4] http://en.wikipedia.org/wiki/Cayley_graph ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] regarding the NSA crypto "breakthrough"
On Thu, Sep 05, 2013 at 10:47:10AM -0700, coderman wrote: > of all the no such agency disclosures, this one fuels the most wild > speculation. It is reported that the journalists deliberately withheld details which are available in Snowden's original documents. Somebody better leak these, fast. The claims are that some code and magic constants have been weakened, but also that NSA still has problems with some methods. We need to know. Obviously, as a short-term workaround there's fallback to expensive/inconvenient methods like one-time pads, but long-term we obviously need new cyphers. Not tainted by any TLA poison. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] integer automata networks for PRNG
Assuming you want to build a family of large-state PRNGs by using random high-dimensional (N>>3) automaton networks (>>10^3 nodes or more) where each node state is computed by a logical function (e.g. XOR) of the node and its neighborhood -- 1) is there prior work on that? 2) which methods would one use to prove/engineer their resistance to reverse engineering state and topology (which can change at each round, by e.g. treating the array of pointers as automaton state itself) from just observing a small window on its state? It seems there's a continuum between one-time pad and sufficiently large-state PRNGs. I can think of using light cones for low-dimensional, regular analoga to show state propagation across volume, but high-dimensional networks pretty much guarantee that information about local state will spread wide even with a few iterations. Obviously, by using a lot of state and randomizing the topology at each round would make ASICfication prohibitively expensive. Obviously, for software implementations this is bandwidth-limited (and guarantees worst-case for memory streaming), and could be accelerated by using a massively parallel system with embedded memory and a suitable n-torus signalling mesh. Thanks for any pointers and/or comments. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Opening Discussion: Speculation on "BULLRUN"
1lwf5sHaPpsKU 3mAC4HnQwlgd61epbLVbNcltp40nz5Soz/tfyyRM2T2VNdkxcriJUezKQRwu+t6d pCbQow9KEpcrdL3TlaQgcvNH0btU5HRnz7EJSrctL+FfZBKUj4jcRCUgASt6gRBd cnrzFcFAYoSgBBR/wJBxUATpzxMl+xZ74zPKJPdaIiA0XPd1F9ZIUe+mzDL+IxHT b08+gUgME9OMpjwToSkoopYL02AkK/GRirC14C2cXieC8JwjrevIoBQmCLUutNK6 XC4sOGrFZ7Z37sXL+1jT =4NbV -END PGP SIGNATURE- ___ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generation being influenced - rumors
- Forwarded message from Andy Isaacson - Date: Fri, 6 Sep 2013 22:24:00 -0700 From: Andy Isaacson To: liberationtech Subject: Re: [liberationtech] Random number generation being influenced - rumors User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote: > On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson wrote: > > This is not to say that RdRand is completely unusable. Putting RdRand > > entropy into a software pool implementation like /dev/urandom (or > > preferably, a higher-assurance multipool design like Fortuna) is a cheap > > way to prevent a putative backdoor from compromising your system state. > > Nearly nothing from what you wrote is relevant to RDRAND, which is not > a pure HWRNG, but implements CTR_DRBG with AES (unclear whether > 128/192/256) from NIST SP 800-90A [1,2]. That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input. Providing accessible "test points" (software interfaces to the innards of the implementation, with documentation of expected behavior between the components) would be the absolute minimum to provide believable assurance of the absence of a backdoor. Better would be documents from Intel of how the chip is designed at the mask level, and a third party mill-and-microphotograph of a retail chip showing that the shipped implementation matches the design. Intel will never go for that, of course, since their chip masks are their jealously guarded IP. Since they can't provide evidence of a lack of a backdoor, any reasonably cautious user should avoid depending on Intel's implementation. -andy -- Liberationtech is a public list whose 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 compa...@stanford.edu. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-talk] NIST approved crypto in Tor?
; ECRYPT and ECRYPT II produced some exceptionally worthwhile results; I hope that whoever makes funding decisions funds a nice targeted ECRYPT III some time. As I said on another mail, I've got a mind to move a lot of our crypto for other reasons, as well. The elephant in the room here is TLS itself. Frankly, I'm starting to think we should cut the Gordian Knot here and start a little independent protocol group of our own if the TLS working group can't get its act together and have one really good ciphersuite some time soon. > The NSA likes playing around. [2][3] (found while searching) > > Oh and I'm not trying fear-mongering here or try to conspire whenever or > not the NSA has subverted cryptographic functions (in one way or another). Yeah, I know how it is. I'm seeing conspiracies under every protocol and in every patch these days. Gotta stay focused, write the best protocols and designs and software I can, and maintain. (And with that in mind I should really start on my weekend soon.) peace, -- Nick -- tor-talk mailing list - tor-t...@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On Sat, Sep 07, 2013 at 10:48:02AM -0700, David Johnston wrote: > It interesting to consider the possibilities of corruption and > deception that may exist in product design. It's a lot more alarming > when it's your own design that is being accused of having been > backdoored. Claiming the NSA colluded with intel to backdoor RdRand > is also to accuse me personally of having colluded with the NSA in > producing a subverted design. I did not. There is no way for us to check what Intel ships. A trustable system must be inspectable, so that we actually don't have to guess what it does, but can actually check. This pretty much rules out CPU-integral RNGs. It has to be a third-party add-on (USB or PCIe), and it has to be open hardware. Additional advantage of a kit-like approach (say, FPGA that ships without a blob that has to be downloaded from a depository) is that you can circument IP issues, and don't have a manufacturer who can be forced into backdooring the system. > A quick googling revealed many such instances of statements to this > effect, strewn across the internet, based on inferences from the > Snowden leaks and resulting Guardian and NYT articles. > > I personally know it not to be true and from my perspective, the > effort we went to improve computer security by making secure random > numbers available and ubiquitous in a low attack-surface model is > now being undermined by speculation that would lead people to use How badly patent-entangled is Intel's RNG? Can the fundamental principle be extracted into an open design? > less available, less secure RNGs. This I expect would serve the > needs of the NSA well. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Political Cypherpunks Trumps Apolitical Cryptography
- Forwarded message from John Young - Date: Sun, 08 Sep 2013 09:12:25 -0400 From: John Young To: cypherpu...@cpunks.org Subject: Political Cypherpunks Trumps Apolitical Cryptography X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 What is striking about discussion on the two cryptography mail lists, both set up to minimize discussing political and social issues to avoid cypherpunks acceptance of them, is the tentative reconsideration of those issues due to Snowden's revelations, miniscule as they are. Notable among those raising the political threat are those who disdained the issue on cypherpunks and stomped off to set up alternatives ham-handedly moderated to cease and desist the "off-topic." A few now say, bray more like it, NSA has betrayed us through political manipulation of officials and the public, and that is an important point which often came up on cypherpunks and still does, with somewhat less complaining about it. For Snowden has shown the political has won out over the technical, and the technicals are fraught with what to do about it, and much fingerpointing is going on along with a few claims of having forewarned this betrayal would happen. No moderation yet has shut down this "off-topic." But much gumming and gnawing of the futility of technical means against the vulgar political. What has been shown in the discussion is that the technical wizards are not nearly as competent at the messy political as they are at technical sophistication. The resulting conversation is a mish-mash of fairly high level technical discourse interleaved with fairly clumsy political opinionating. So technical clubs are being swung to answer political jabs, that is petty squabblling and exchange of slurs has replaced rational discourse. Thus the convo has become politicized with as much stupidity and ignorance as sharp thinking and mutual respect. NSA and its bosses would be happy if this became the norm in cryptography as in the real world. And some opine that this outcome is being, and has been in the past, and will be in the future, orchestrated for just that result. That sounds like what cypherpunks was set up to combat, the withdrawal from politcial affairs into safe sanctuary of infallible mathematics coated with unending challengences to implement illusory protection from political mayhem. So it has come to pass, there is no refuge from politics, and the once reviled tin-hats of conspiracy theories are replacing anomymous masks, especially by the best and brightest cryptographers who have been hoodwinked far more than dreamed of in earliest days of cypherpunks. Still, there are die-hard PR-driven comsec experts rolling out advice for what to do to protect the public -- meaning, cynically protecting their severely damaged reputation of "concern for the public interest (R)". Not yet willing to admit losing the comsec and privacy war so avidly promoted with HTTPS, SSL, PGP, PFS, OTR, Tor, on and on, they continue to hustle comsec customers with promises of here's what we have got to do, take it from us experienced veterans (read my remarks, hear my TV interviews, read my messages on cryptography, gorge on recyclings on Slashdot, Twitter, Reddit, Voice of America, EFF. Guardian, New York Times, ProPublica, ACLU, EPIC, on and on): Lo, special prosecute NSA, take it to the courts, a tired political gambit for media semaphoring, fund raising, conceding technical defeat and begging political rescue by what's that you say, account churning lawyers, political lobbyists and journalistic hacks. That is so obnoxious, murmurs the cryptography mail lists, so opportunistically off-topic, moderator do your censoring, let's get back to the good stuff. Despite the murmurrings there recurs calls for "cut the cowardly shit, let's fight." One guess who said that. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-talk] NIST approved crypto in Tor?
- Forwarded message from Gregory Maxwell - Date: Sun, 8 Sep 2013 06:44:57 -0700 From: Gregory Maxwell To: "This mailing list is for all discussion about theory, design, and development of Onion Routing." Subject: Re: [tor-talk] NIST approved crypto in Tor? Reply-To: tor-t...@lists.torproject.org On Sat, Sep 7, 2013 at 8:09 PM, Gregory Maxwell wrote: > On Sat, Sep 7, 2013 at 4:08 PM, anonymous coward > wrote: >> Bruce Schneier recommends *not* to use ECC. It is safe to assume he >> knows what he says. > > I believe Schneier was being careless there. The ECC parameter sets > commonly used on the internet (the NIST P-xxxr ones) were chosen using > a published deterministically randomized procedure. I think the > notion that these parameters could have been maliciously selected is a > remarkable claim which demands remarkable evidence. Okay, I need to eat my words here. I went to review the deterministic procedure because I wanted to see if I could repoduce the SECP256k1 curve we use in Bitcoin. They don't give a procedure for the Koblitz curves, but they have far less design freedom than the non-koblitz so I thought perhaps I'd stumble into it with the "most obvious" procedure. The deterministic procedure basically computes SHA1 on some seed and uses it to assign the parameters then checks the curve order, etc.. wash rinse repeat. Then I looked at the random seed values for the P-xxxr curves. For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90. _No_ justification is given for that value. The stated purpose of the "veritably random" procedure "ensures that the parameters cannot be predetermined. The parameters are therefore extremely unlikely to be susceptible to future special-purpose attacks, and no trapdoors can have been placed in the parameters during their generation". Considering the stated purpose I would have expected the seed to be some small value like ... "6F" and for all smaller values to fail the test. Anything else would have suggested that they tested a large number of values, and thus the parameters could embody any undisclosed mathematical characteristic whos rareness is only bounded by how many times they could run sha1 and test. I now personally consider this to be smoking evidence that the parameters are cooked. Maybe they were only cooked in ways that make them stronger? Maybe SECG also makes a somewhat curious remark: "The elliptic curve domain parameters over (primes) supplied at each security level typically consist of examples of two different types of parameters — one type being parameters associated with a Koblitz curve and the other type being parameters chosen verifiably at random — although only verifiably random parameters are supplied at export strength and at extremely high strength." The fact that only "verifiably random" are given for export strength would seem to make more sense if you cynically read "verifiably random" as backdoored to all heck. (though it could be more innocently explained that the performance improvements of Koblitz wasn't so important there, and/or they considered those curves weak enough to not bother with the extra effort required to produce the Koblitz curves). -- tor-talk mailing list - tor-t...@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [Cryptography] Opening Discussion: Speculation on "BULLRUN"
Forwarded with permission. So there *is* a BTNS implementation, after all. Albeit only for OpenBSD -- but this means FreeBSD is next, and Linux to follow. - Forwarded message from Andreas Davour - Date: Sun, 8 Sep 2013 09:10:44 -0700 (PDT) From: Andreas Davour To: Eugen Leitl Subject: [Cryptography] Opening Discussion: Speculation on "BULLRUN" X-Mailer: YahooMailWebService/0.8.156.576 Reply-To: Andreas Davour > Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption > mode for > IPsec) implementations, and even the authors of the RFC are not aware of any. > Obviously, having a working OE BTNS implementation in Linux/*BSD would be a > very valuable thing, as an added, transparent protection layer against > passive attacks. There are many IPsec old hands here, it is probably just a > few man-days > worth of work. It should be even possible to raise some funding for such a > project. Any takers? Hi. I saw this message in the archive, and have not figured out how to reply to that one. But I felt this knowledge needed to be spread. Maybe you can post it to the list? My friend "MC" have in fact implemented BTNS! Check this out: http://hack.org/mc/projects/btns/ I think I can speak for him and say that he would love to have that implementation be known to the others on the list, and would love others to add to his work, so we can get real network security without those spooks spoiling things. /andreas -- "My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me." -- Edward Snowden's Father - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] very little is missing for working BTNS in Openswan
Just got word from an Openswan developer: " To my knowledge, we never finished implementing the BTNS mode. It wouldn't be hard to do --- it's mostly just conditionally commenting out code. " There's obviously a large potential deployment base for BTNS for home users, just think of Openswan/OpenWRT. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
Forwarded without permission, hence anonymized: " Hey, I had a look at SEC2 and the TLS/SSH RFCs. SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG! TLS specifies you can use those two curves as well... Surely that's not coincidence.. " signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] IETF: Security and Pervasive Monitoring
http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ Security and Pervasive Monitoring The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use. So the reports about large-scale monitoring of Internet traffic and users disturbs us greatly. We knew of interception of targeted individuals and other monitoring activities, but the scale of recently reported monitoring is surprising. Such scale was not envisaged during the design of many Internet protocols, but we are considering the consequence of these kinds of attacks. Of course, it is hard to know for sure from current reports what attack techniques may be in use. As such, it is not so easy to comment on the specifics from an IETF perspective. Still, the IETF has some long standing general principles that we can talk about, and we can also talk about some of the actions we are taking. In 1996, RFC 1984 articulated the view that encryption is an important tool to protect privacy of communications, and that as such it should be encouraged and available to all. In 2002, we decided that IETF standard protocols must include appropriate strong security mechanisms, and established this doctrine as a best current practice, documented in RFC 3365. Earlier, in 2000 the IETF decided not to consider requirements for wiretapping when creating and maintaining IETF standards, for reasons stated in RFC 2804. Note that IETF participants exist with positions at all points of the privacy/surveillance continuum, as seen in the discussions that lead to RFC 2804. As privacy has become increasingly important, the Internet Architecture Board (IAB) developed guidance for handling privacy considerations in protocol specifications, and documented that in RFC 6973. And there are ongoing developments in security and privacy happening within the IETF all the time, for example work has just started on version 1.3 of the Transport Layer Security (TLS, RFC 5246) protocol which aims to provide better confidentiality during the early phases of the cryptographic handshake that underlies much secure Internet traffic. Recent days have also seen an extended and welcome discussion triggered by calls for the IETF to build better protections against wide-spread monitoring. As that discussion makes clear, IETF participants want to build secure and deployable systems for all Internet users. Indeed, addressing security and new vulnerabilities has been a topic in the IETF for as long as the organisation has existed. Technology alone is, however, not the only factor. Operational practices, laws, and other similar factors also matter. First of all, existing IETF security technologies, if used more widely, can definitely help. But technical issues outside the IETF’s control, for example endpoint security, or the properties of specific products or implementations also affect the end result in major ways. So at the end of the day, no amount of communication security helps you if you do not trust the party you are communicating with or the devices you are using. Nonetheless, we’re confident the IETF can and will do more to make our protocols work more securely and offer better privacy features that can be used by implementations of all kinds. So with the understanding of limitations of technology-only solutions, the IETF is continuing its mission to improve security in the Internet. The recent revelations provide additional motivation for doing this, as well as highlighting the need to consider new threat models. We should seize this opportunity to take a hard look at what we can do better. Again, it is important to understand the limitations of technology alone. But here are some examples of things that are already ongoing: We’re having a discussion as part of the development of HTTP/2.0 as to how to make more and better use of TLS, for example to perhaps enable clients to require the use of security and not just have to react to the HTTP or HTTPS URLs chosen by servers. We’re having discussions as to how to handle the potentially new threat model demonstrated by the recent revelations so that future protocol designs can take into account potential pervasive monitoring as a known threat model. We’re considering ways in which better use can be made of existing protocol features, for example, better guidance as to how to deploy TLS with Perfect Forward Secrecy, which makes applications running over TLS more robust if server private keys later leak out. We’re constantly updating specifications to deprecate older, weaker cryptographic algorithms and allocate code points for currently strong algorithm choices so those can be used with Internet protocols. And we are confident that discussions on this topic will motivate IETF participants to do more work on these and further related topics. But don’t think about all this just in terms of the recent revelations. The security and priv
Re: [cryptography] [Cryptography] Opening Discussion: Speculation on "BULLRUN"
- Forwarded message from "Jeffrey I. Schiller" - Date: Sun, 8 Sep 2013 21:23:33 -0400 From: "Jeffrey I. Schiller" To: John Gilmore Cc: Cryptography Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mutt/1.5.21 (2010-09-15) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 06, 2013 at 05:22:26PM -0700, John Gilmore wrote: > Speaking as someone who followed the IPSEC IETF standards committee > pretty closely, while leading a group that tried to implement it and > make so usable that it would be used by default throughout the > Internet, I noticed some things: > ... Speaking as one of the Security Area Directors at the time... I have to disagree with your implication that the NSA intentionally fouled the IPSEC working group. There were a lot of people working to foul it up! I also don’t believe that the folks who participated, including the folks from the NSA, were working to weaken the standard. I suspect that the effort to interfere in standards started later then the IPSEC work. If the NSA was attempting to thwart IETF security standards, I would have expected to also see bad things in the TLS working group and the PGP working group. There is no sign of their interference there. The real (or at least the first) problem with the IPSEC working group was that we had a good and simple solution, Photuris. However the document editor on the standard decided to claim it (Photuris) as his intellectual property and that others couldn’t recommend changes without his approval. This effectively made Photuris toxic in the working group and we had to move on to other solutions. This is one of the events that lead to the IETF’s “Note Well” document and clear policy on the IP associated with contributions. Then there was the ISAKMP (yes, an NSA proposal) vs. SKIP. As Security AD, I eventually had to choose between those two standards because the working group could not generate consensus. I believed strongly enough that we needed an IPSEC solution so I decided to choose (as I promised the working group I would do if they failed to!). I chose ISAKMP. I posted a message with my rationale to the IPSEC mailing list, I’m sure it is still in the archives. I believe that was in 1996 (I still have a copy somewhere in my personal archives). At no point was I contacted by the NSA or any agent of any government in an attempt to influence my decision. Folks can choose to believe this statement, or not. IPSEC in general did not have significant traction on the Internet in general. It eventually gained traction in an important niche, namely VPNs, but that evolved later. IPSEC isn’t useful unless all of the end-points that need to communicate implement it. Implementations need to be in the OS (for all practical purposes). OS vendors at the time were not particularly interested in encryption of network traffic. The folks who were interested were the browser folks. They were very interested in enabling e-commerce, and that required encryption. However they wanted the encryption layer someplace where they could be sure it existed. An encryption solution was not useful to them if it couldn’t be relied upon to be there. If the OS the user had didn’t have an IPSEC layer, they were sunk. So they needed their own layer. Thus the Netscape guys did SSL, and Microsoft did PCT and in the IETF we were able to get them to work together to create TLS. This was a *big deal*. We shortly had one deployed interoperable encryption standard usable on the web. If I was the NSA and I wanted to foul up encryption on the Internet, the TLS group is where the action was. Yet from where I sit, I didn’t see any such interference. If we believe the Edward Snowden documents, the NSA at some point started to interfere with international standards relating to encryption. But I don’t believe they were in this business in the 1990’s at the IETF. -Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSLSMV8CBzV/QUlSsRAigkAKCU6erw1U7FOt7A1QdItlGbFRfo+gCfeMg1 0Woyz0FyKqKYqS+gZFQWEf0= =yWOw -END PGP SIGNATURE- ___ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Backdoors in software
On Mon, Sep 09, 2013 at 01:50:54PM -0500, Nicolai wrote: > On Mon, Sep 09, 2013 at 02:20:35PM +0200, David D wrote: > > > TrueCrypt can be assumed "ok" based on Greenwald using it.If Snowden > > knew of a hole in TrueCrypt then Greenwald would not be using it. IMO. > > I don't think this is a useful criteria. After all, Greenwald probably > uses Windows, right? Schneier uses Windows, too. http://www.truecrypt.org/docs/supported-operating-systems TrueCrypt currently supports the following operating systems: Windows 7 (32-bit and 64-bit) Windows Vista (32-bit and 64-bit) Windows XP (32-bit and 64-bit) Windows Server 2008 R2 (64-bit) Windows Server 2008 (32-bit and 64-bit) Windows Server 2003 (32-bit and 64-bit) Windows 2000 SP4 Mac OS X 10.8 Mountain Lion (32-bit and 64-bit) Mac OS X 10.7 Lion (32-bit and 64-bit) Mac OS X 10.6 Snow Leopard (32-bit) Mac OS X 10.5 Leopard Mac OS X 10.4 Tiger Linux (32-bit and 64-bit versions, kernel 2.6 or compatible) Note: The following operating systems (among others) are not supported: Windows RT, Windows 2003 IA-64, Windows 2008 IA-64, Windows XP IA-64, and the Embedded/Tablet versions of Windows. > NB: I'm not making any claim for or against TrueCrypt. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Random number generation influenced, HW RNG
- Forwarded message from Eric Young - Date: Tue, 10 Sep 2013 20:58:20 +1000 From: Eric Young To: Eugen Leitl Cc: cypherpu...@al-qaeda.net, i...@postbiota.org, zs-...@zerostate.is, Cryptography List Subject: Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG X-Mailer: Evolution 3.2.3-0ubuntu6 On Sun, 2013-09-08 at 13:27 +0200, Eugen Leitl wrote: > - Forwarded message from "James A. Donald" - > On 2013-09-08 3:48 AM, David Johnston wrote: > > Claiming the NSA colluded with intel to backdoor RdRand is also to > > accuse me personally of having colluded with the NSA in producing a > > subverted design. I did not. > > Well, since you personally did this, would you care to explain the > very strange design decision to whiten the numbers on chip, and not > provide direct access to the raw unwhitened output. > > A decision that even assuming the utmost virtue on the part of the > designers, leaves open the possibility of malfunctions going > undetected. I may have missed this part of the thread, but I'm interested in knowing the rational for letting the hyper-visor intercept the RDRAND call and return any value it likes, bypassing the random hardware. I've had one person speculate it would be useful for keeping 2 CPUs in sync, (the TSC can also be intercepted), but it does worry me that RDRAND calls can be rendered predictable by a compromised VM. eric For those interested, Intel document 325462.pdf, "Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C" Page 'Vol. 3C 27-23', Table 27-12. Format of the VM-Exit Instruction-Information Field as Used for RDRAND - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The One True Cipher Suite
- Forwarded message from Jerry Leichter - Date: Tue, 10 Sep 2013 07:42:55 -0400 From: Jerry Leichter To: Phillip Hallam-Baker Cc: "cryptogra...@metzdowd.com" , ianG Subject: Re: [Cryptography] The One True Cipher Suite X-Mailer: Apple Mail (2.1283) On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote: > Steve Bellovin has made the same argument and I agree with it. Proliferation > of cipher suites is not helpful. > > The point I make is that adding a strong cipher does not make you more > secure. Only removing the option of using weak ciphers makes you more secure. I'm not so sure I agree. You have to consider the monoculture problem, combined with the threat you are defending against. The large burst of discussion on this list was set off by Perry's request for ways to protect against the kinds of broad-scale, gather-everything attacks that Snowden has told us the NSA is doing. So consider things from the side of someone attempting to mount this kind of attack: 1. If everyone uses the same cipher, the attacker need only attack that one cipher. 2. If there are thousands of ciphers in use, the attacker needs to attack some large fraction of them. As a defender, if I go route 1, I'd better be really, really, really sure that my cipher won't fall to any attacks over its operational lifetime - which, if it's really universal, will extend many years *even beyond a point where a weakness is found*. On the other hand, even if most of the ciphers in my suite are only moderately strong, the chance of any particular one of them having been compromised is lower. This is an *ensemble* argument, not an *individual* argument. If I'm facing an attacker who is concentrating on my messages in particular, then I want the strongest cipher I can find. Another way of looking at this is that Many Ciphers trades higher partial failure probabilities for lower total/catastrophic failure probabilities. Two things are definitely true, however: 1. If you don't remove ciphers that are found to be bad, you will eventually pollute your ensemble to the point of uselessness. If you want to go the "many different ciphers" approach, you *must* have an effective way to do this. 2. There must be a large set of potentially good ciphers out there to choose from. I contend that we're actually in a position to create reasonably good block ciphers fairly easily. Look at the AES process. Of the 15 round 1 candidates, a full third made it to the final round - which means that no significant attacks against them were known. Some of the rejected ones failed due to minor "certificational" weaknesses - weaknesses that should certainly lead you not to want to choose them as "the One True Cipher", but which would in and of themselves not render breaking them trivial. And, frankly, for most purposes, any of the five finalists would have been fine - much of the final choice was made for performance reasons. (And, considering Dan Bernstein's work on timing attacks based on table lookups, the performance choices made bad assumptions about actual hardware!) I see no reason not to double-encrypt, using different keys and any two algorithms from the ensemble. Yes, meet-in-the-middle attacks mean this isn't nearly as strong as you might naively think, but it ups the resource demands on the attacker much more than on the defender. Now, you can argue that AES - the only cipher really in the running for the One True Symmetric Cipher position at the moment - is so strong that worrying about attacks on it is pointless - the weaknesses are elsewhere. I'm on the fence about that; it's hard to know. But if you're going to argue for One True Cipher, you must be explicit about this (inherently unprovable) assumption; without it your argument fails. The situation is much more worse for the asymmetric case: We only have a few alternatives available and there are many correlations among their potential weaknesses, so the Many Ciphers approach isn't currently practical, so there's really nothing to debate at this point. Finally, I'll point out that what we know publicly about NSA practices says that (a) they believe in multiple ciphers for different purposes; (b) they believe in the strength of AES, but only up to a certain point. At this point, I'd be very leery of taking anything NSA says or reveals about it practices at face value, but there it is. -- Jerry ___ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org ___
[cryptography] SPDZ, a practical protocol for Multi-Party Computation
http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_result_in_more_secure_computing.asp Breakthrough in cryptography could result in more secure computing (9/10/2013) Tags: computer science, research, security, cryptography Nigel Smart, Professor of Cryptology New research to be presented at the 18th European Symposium on Research in Computer Security (ESORICS 2013) this week could result in a sea change in how to secure computations. The collaborative work between the University of Bristol and Aarhus University (Denmark) will be presented by Bristol PhD student Peter Scholl from the Department of Computer Science. The paper, entitled 'Practical covertly secure MPC for dishonest majority - or: Breaking the SPDZ limits', builds upon earlier joint work between Bristol and Aarhus and fills in the missing pieces of the jigsaw from the groups prior work that was presented at the CRYPTO conference in Santa Barbara last year. The SPDZ protocol (pronounced "Speedz") is a co-development between Bristol and Aarhus and provides the fastest protocol known to implement a theoretical idea called "Multi-Party Computation". The idea behind Multi-Party Computation is that it should enable two or more people to compute any function of their choosing on their secret inputs, without revealing their inputs to either party. One example is an election, voters want their vote to be counted but they do not want their vote made public. The protocol developed by the universities turns Multi-Party Computation from a theoretical tool into a practical reality. Using the SPDZ protocol the team can now compute complex functions in a secure manner, enabling possible applications in the finance, drugs and chemical industries where computation often needs to be performed on secret data. Nigel Smart, Professor of Cryptology in the University of Bristol's Department of Computer Science and leader on the project, said: "We have demonstrated our protocol to various groups and organisations across the world, and everyone is impressed by how fast we can actually perform secure computations. "Only a few years ago such a theoretical idea becoming reality was considered Alice in Wonderland style over ambitious hope. However, we in Bristol realised around five years ago that a number of advances in different areas would enable the pipe dream to be achieved. It is great that we have been able to demonstrate our foresight was correct." The University of Bristol is now starting to consider commercialising the protocol via a company Dyadic Security Limited, co-founded by Professor Smart and Professor Yehuda Lindell from Bar-Ilan University in Israel. Note: This story has been adapted from a news release issued by the University of Bristol signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] NIST reopens RNG public comment period
http://csrc.nist.gov/publications/PubsDrafts.html Sep. 9, 2013 SP 800-90 A Rev 1 B and C DRAFT Draft SP 800-90 Series: Random Bit Generators 800-90 A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators 800-90 B: Recommendation for the Entropy Sources Used for Random Bit Generation 800-90 C: Recommendation for Random Bit Generator (RBG) Constructions In light of recent reports, NIST is reopening the public comment period for Special Publication 800-90A and draft Special Publications 800-90B and 800-90C. NIST is interested in public review and comment to ensure that the recommendations are accurate and provide the strongest cryptographic recommendations possible. The public comments will close on November 6, 2013. Comments should be sent to rbg_comme...@nist.gov. In addition, the Computer Security Division has released a supplemental ITL Security Bulletin titled "NIST Opens Draft Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, For Review and Comment (Supplemental ITL Bulletin for September 2013)" to support the draft revision effort. Draft SP 800-90 A Rev. 1 (721 KB) Draft SP 800-90 B (800 KB) Draft SP 800-90 C (1.1 MB) signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Stealthy Dopant-Level Hardware Trojans
http://people.umass.edu/gbecker/BeckerChes13.pdf Stealthy Dopant-Level Hardware Trojans ? Georg T. Becker1 , Francesco Regazzoni2 , Christof Paar1,3 , and Wayne P. Burleson1 1University of Massachusetts Amherst, USA 2TU Delft, The Netherlands and ALaRI - University of Lugano, Switzerland 3Horst ortz Institut for IT-Security, Ruhr-Universiat Bochum, Germany Abstract. In recent years, hardware Trojans have drawn the attention of governments and industry as well as the scientific community. One of the main concerns is that integrated circuits, e.g., for military or critical infrastructure applications, could be maliciously manipulated during the manufacturing process, which often takes place abroad. However, since there have been no reported hardware Trojans in practice yet, little is known about how such a Trojan would look like, and how dicult it would be in practice to implement one. In this paper we propose an extremely stealthy approach for implementing hardware Trojans below the gate level, and we evaluate their impact on the security of the target device. Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against "golden chips". We demonstrate the ectiveness of our approach by inserting Trojans into two designs | a digital post-processing derived from Intel's cryptographically secure RNG design used in the Ivy Bridge processors and a side-channel resistant SBox implementation and by exploring their detectability and their ects on security. Keywords: Hardware Trojans, malicious hardware, layout modifications, Trojan side-channel signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] "Ibis: An Overlay Mix Network for Microblogging" by Ian Goldberg
- Forwarded message from Steve Weis - Date: Wed, 18 Sep 2013 08:50:09 -0700 From: Steve Weis To: "liberationt...@lists.stanford.edu" Subject: [liberationtech] "Ibis: An Overlay Mix Network for Microblogging" by Ian Goldberg Reply-To: liberationtech Ian Goldberg is speaking about "Ibis: An Overlay Mix Network for Microblogging" today at the Stanford security seminar. The talk is 4:30pm in the Gates building, room 463A. http://crypto.stanford.edu/seclab/sem-12-13/goldberg.html Abstract: Microblogging services such as Twitter are extremely popular. While they are commonly used by people who wish to reveal their names and friends to the world, some users, such as activists on the ground, may wish to be able to post without automatically revealing their identities or locations. An obvious approach is to use a low-latency anonymity system, such as Tor. However, low-latency systems fall prey to end-to-end timing attacks easily accomplished by an ISP or a government monitoring clients while also watching for posts to appear in real time on the microblogging site. We present Ibis, a high-latency mix network designed specifically for microblogging. Ibis is an overlay network: the mix nodes can be microblogging clients that come online only sporadicly, and the intermediate encrypted messages are themselves posted as microblogged entries. We accomplish this through a novel cryptographic mix message format that uses only 47 bytes of overhead, while maintaining three-hop, 128-bit security against offline attack. This is joint work with Paul Hendry. Bio: Ian Goldberg is an Associate Professor of Computer Science and a University Research Chair at the University of Waterloo, where he is a founding member of the Cryptography, Security, and Privacy (CrySP) research group. He holds a Ph.D. from the University of California, Berkeley, where he discovered serious weaknesses in a number of widely deployed security systems, including those used by cellular phones and wireless networks. He also studied systems for protecting the personal privacy of Internet users, which led to his role as Chief Scientist at Zero-Knowledge Systems (now Radialpoint). His research currently focuses on developing usable and useful technologies to help Internet users maintain their security and privacy. He is a Senior Member of the ACM and a winner of the Early Researcher Award, the Outstanding Young Computer Science Researcher Award, and the Electronic Frontier Foundation's Pioneer Award. -- 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 compa...@stanford.edu. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] "Ibis: An Overlay Mix Network for Microblogging" by Ian Goldberg
- Forwarded message from Steve Weis - Date: Wed, 18 Sep 2013 21:50:45 -0700 From: Steve Weis To: liberationtech Subject: Re: [liberationtech] "Ibis: An Overlay Mix Network for Microblogging" by Ian Goldberg Reply-To: liberationtech It was an interesting talk. The gist is that they've shrunk the overhead of the Sphinx mix net ( http://research.microsoft.com/en-us/um/people/gdane/papers/sphinx-eprint.pdf) to 47 bytes. They've done this by removing the requirement for message replies and using curve25519 for ECC. They've also encoded ciphertext with CJK characters to make up most of the 47-byte overhead and let you post close to 140 ASCII characters. That lets them use Twitter as a medium for mix net messages. Users will encrypt messages using a chosen path of Ibis mix net nodes, label them with a hash tag, and either tweet the encrypted message or send it directly through an Ibis node IP address. Ibis nodes will watch for messages with specific tags. When they detect them, they'll decrypt a mix net layer and pass them along to the next node. The final node will post the payload as a retweet. They are still trying to push through a security proof for the paper before posting it, along with a command-line client. I think Ian Goldberg said it would be up at http://ibis.uwaterloo.ca. On Wed, Sep 18, 2013 at 7:09 PM, Tom Ritter wrote: > This looks interesting! Am I being dense, or is there a paper or > slides or anything somewhere non-Stanfordites can read? > > -tom > -- > 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 > compa...@stanford.edu. > -- 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 compa...@stanford.edu. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Deleting data on a flash?
On Mon, Sep 23, 2013 at 11:02:45AM +0300, ianG wrote: > On 23/09/13 07:12 AM, Dev Random wrote: > >I've been thinking about this for a while now and I don't see a way to > >do this with today's mobile devices without some external help. > > > >The issue is that it's pretty much impossible to delete data securely > >from a flash device. > > Why is that? I presume it's due to extra blocks due to overprovisioning. There is no way to verify the block you've zeroed or randomized has been really overwritten. It is much easier to destroy the secret of a cryptofs. I've just looked, and there seems to be no easy way to mount an encrypted partition on Android, though GuardianProject has a LUKS howto. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
