Re: [Cryptography] Thoughts on hardware randomness sources
On 09/13/2013 11:32 PM, Jerry Leichter wrote: On Sep 12, 2013, at 11:06 PM, Marcus D. Leech wrote: There are a class of hyper-cheap USB audio dongles with very uncomplicated mixer models. A small flotilla of those might get you some fault-tolerance. My main thought on such things relates to servers, where power consumption isn't really much of an issue I'm not sure what servers you're talking about here. If by server you mean one of those things in a rack at Amazon or Google or Rackspace - power consumption, and its consequence, cooling - is *the* major issue these days. Also, the servers used in such data centers don't have multiple free USB inputs - they may not have any. If by server you mean some quite low-power box in someone's home ... power is again an issue. People want these things small, fan-free, and dead reliable. And they are increasingly aware of the electric bills always-on devices produce. About the only server for which power is not an issue is one of those extra-large desktops that small businesses use. -- Jerry I was mostly contrasting with mobile systems, where power consumption is at an absolute premium. The USB sound systems I'm thinking of consume 350mW while operating, and about 300uW when idle. A couple or three of those on even a stripped-down server would contribute in only the smallest way to extra power consumption. And the extra computational load? When these servers things are running flat-out serving up secured connections? I would guess the phrase an inconsiderable trifle would apply. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On 09/12/2013 10:38 PM, Thor Lancelot Simon wrote: The audio subsystem actually posed *two* obvious opportunities: amplifier noise from channels with high final stage gain but connected by a mixer to muted inputs, and clock skew between system timers and audio sample clocks. The former requires a lot of interaction with specific audio hardware at a low level, and with a million different wirings of input to mixer to ADC, it looks hard (though surely not impossible) to quickly code up anything generally useful. The latter would be easier, and it has the advantage you can do it opportunistically any time the audio subsystem is doing anything *else*, without even touching the actual sample data. Unfortunately, both of them burn power like the pumps at Fukushima, which makes them poorly suited for the small systems with few other sources of entropy which were one of my major targets for this. So they are still sitting on some back back back burner. Someday, perhaps... Thor There are a class of hyper-cheap USB audio dongles with very uncomplicated mixer models. A small flotilla of those might get you some fault-tolerance. My main thought on such things relates to servers, where power consumption isn't really much of an issue. Similarly these hyper-cheap ($10.00) DVB-T dongles based on the RTL2832U can be made to run in SDR mode, and give you a basebanded sample stream of a wide variety of tuned RF frequencies--put a terminator on the input, chose your frequency, crank up the gain, and pull samples until you're bored This topic has suddenly become interesting to me in my work life, so I'm currently looking at the sensors API for Android. I thought I had left Android work behind, but it's coming back to haunt me. I was playing with the sensor outputs on a Nexus tablet today, and it has an impressive array of sensors. I suspect each of them could contribute a few bits/second of entropy without too much trouble. More investigation is necessary. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On 09/11/2013 07:18 PM, Perry E. Metzger wrote: The attraction of methods that use nothing but a handful of transistors is that they can be fabricated on chip and thus have nearly zero marginal cost. The huge disadvantage is that if your opponent can convince chip manufacturers to introduce small changes into their design, you're in trouble. Perry And this is the reason that I'd be in favour of diversity -- using sound cards, lava-lamps, etc, etc. Sources that don't explicitly identify themselves as the random number generator. There's no way for a bad actor to cover all the bases, and since these things are primarily used for things other than random-number sources, it may be hard to break them in ways that doesn't also break their primary purpose (although, if you're just mucking with the low-order noise bits of some arbitrarily-chosen digitization of a real-world source, it would be hard to tell the difference). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On 09/10/2013 12:04 PM, Rob Kendrick wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) I haven't actually looked at the code. Conceptually, anything with an ADC can produce thermal and or 1/f noise in the lowest-order bits. Even if it's somewhat biased (like having 60Hz hum embedded in it), with a suitable whitening function, it should produce high-quality entropy at rates of at least several hundred bits/second. The idea is to have *diversity* of physical random sources, to make it difficult for bad actors to subvert said hardware. It's fairly easy to audit these sources of random bits, since said bits won't have had any processing done to them in support of their random properties (unlike the Intel HW RNG). But this is just one aspect of a much-larger problem of trusting trust (in the Thompson sense). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Thoughts on hardware randomness sources
I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Similarly, any hardware with an ADC input can be used as a hardware random noise source, simply by cranking up the gain to suitable levels where the low-order bit is sampling thermal noise. I currently play in the Software Defined Radio space, and there are these very-cheap SDR dongles that could easily be used as a hardware random noise source. I think it would be hard for NSA to hack *all* hardware that includes an ADC and some gain in front of it, since there's a dizzying array of it available, cheaply, for PC hardware. A related issue is getting sites to *use* enhanced random sources, even when easy and cheap. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help
On 09/07/2013 06:57 PM, james hughes wrote: PFS may not be a panacea but does help. There's no question in my mind that PFS helps. I have, in the past, been very in much favor of turning on PFS support in various protocols, when it has been available. And I fully understand what the *purpose* of PFS is. But it's not entirely clear to me that it will help enough in the scenarios under discussion. If we assume that mostly what NSA are doing is acquiring a site RSA key (either through donation on the part of the site, or through factoring or other means), then yes, absolutely, PFS will be a significant roadblock. If, however, they're getting session-key material (perhaps through back-doored software, rather than explicit cooperation by the target website), the PFS does nothing to help us. And indeed, that same class of compromised site could just as well be leaking plaintext. Although leaking session keys is lower-profile. I think all this amounts to a preamble for a call to think deeply, again, about end-to-end encryption.I used OTR on certain chat sessions, for example, because the consequences of the server in the middle disclosing the contents of those conversations protected by OTR could have dire consequences for one of the parties involved. Jeff Schiller pointed out a little while ago that the crypto-engineering community have largely failed to make end-to-end encryption easy to use. There are reasons for that, some technical, some political, but it is absolutely true that end-to-end encryption, for those cases where end to end is the obvious and natural model, has not significantly materialized on the Internet. Relatively speaking, a handful of crypto-nerds use end-to-end schemes for e-mail and chat clients, and so on, but the vast majority of the Internet user-space? Not so much. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help
It seems to me that while PFS is an excellent back-stop against NSA having/deriving a website RSA key, it does *nothing* to prevent the kind of cooperative endpoint scenario that I've seen discussed in other forums, prompted by the latest revelations about what NSA has been up to. But if your fave website (gmail, your bank, etc) is disclosing the session-key(s) to the NSA, or has deliberately-weakened session-key negotiation in some way, then PFS doesn't help you. I agree that if the scenario is NSA has a database of RSA keys of 'popular sites' then PFS helps tremendously. But if the scenario goes deeper into the cooperative endpoint territory, then waving the PFS flag is perhaps like playing the violin on the deck of the Titantic. Do we now strongly suspect that NSA have a flotilla of TWIRL (or similar) machines, so that active cooperation of websites isn't strictly necessary to derive their (weaker) RSA secret keys? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
The magic of public key crypto is that it gets rid of the key management problem -- if I'm going to communicate with you with symmetric crypto, how do I get the keys to you? The pain of it is that it replaces it with a new set of problems. Those problems include that the amazing power of public-key crypto tempts one to do things that may not be wise. I find public-key cryptography to be full of dirty little secrets. Some of the notions inherent in public-key *infrastructure* are, on the face of them, preposterous. Consider the notion of a certificate authority. I am to trust some third party (the CA) that I've never met, and have not the slightest reason to trust, is able to make a believable assertion about the identity (and corresponding public-key binding), of some *other* party I've never met, and have no real reason to trust. It always struck me as another instance of there's no problem in CS that can't be solved by adding another layer of abstraction. I think this is an instance of a general problem with digitally-signed documents of all kinds: confusion about exactly what they are--a signature on a document (like a certificate) says nothing about the *essential truth* of the statements contained within the document. When SlushySign issues a certificate for www.crowbars-r-us.com, there's a subtle distinction between we believe this to be the appropriate binding between this public-key, and an entitity known as www.crowbars-r-us.com and this really is the binding between this pubic-key, and the entity you all know as www.crowbars-r-us.com. I started thinking about the essential truth problem back when the whole TPM thing was popular, and proponents were talking as if the digital signature of a computer stating that it was sane was somehow the same is said computer actually being sane. Absent independent verification, there's no way to distinguish a strongly-signed lie from a strongly-signed truth. That isn't necessarily a problem that's confined to PK systems. Any digital-signature scheme has that problem. The other thing that I find to be a dirty little secret in PK systems is revocation. OCSP makes things, in some ways, better than CRLs, but I still find them to be a kind of swept under the rug problem when people are waxing enthusiastic about PK systems. However, PK is the only pony we've managed to bring to this circus, so, we we make do with making the dirty little secrets as inoffensive as we can. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On 09/07/2013 12:04 AM, Ben Laurie wrote: On 26 August 2013 22:43, Perry E. Metzger pe...@piermont.com mailto:pe...@piermont.com wrote: (I would prefer to see hybrid capability systems in such applications, like Capsicum, though I don't think any such have been ported to Linux and that's a popular platform for such work.) FWIW, we're working on a Linux port of Capsicum. Help is always welcome :-) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography I implemented a lightweight, tightly-focused (well, it started out that way), capabilities-like system for Android kernels last year. It was a monumental PITA largely due to interior kernel-side APIs changing so frequently across kernel versions. We had mechanisms for binding capabilities to ELF binaries in a way that the kernel could verify. The project failed, largely because it kept being dragged around by marketing so often, that we never got it really nicely robust in any given direction. This week, it's a floor polish. Next week, it's a turbine maintenance system. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
