Re: [cryptography] Fwd: [RFC][PATCH 0/6] /dev/random - a new approach
On Fri, Apr 22, 2016 at 04:49:54PM +0200, Sven M. Hallberg wrote: > > I developed a different approach, which I call Linux Random Number Generator > > (LRNG) to collect entropy within the Linux kernel. The main improvements > > compared to the legacy /dev/random is to provide sufficient entropy during > > boot > > time as well as in virtual environments and when using SSDs. > > After reading the paper, it is not clear to me how this goal is > achieved. As far as I can see, no new sources of entropy are > introduced; in fact a point is made to use only interrupt timings, > arguing that these effectively include other events. Why does this > design make more entropy available during boot and with solid-state > storage? Indeed. I think it would be desirable to clearly separate work to reorganize and modernize the core entropy-gathering and DRBG constructions (which closely parallels work Taylor Campbell and I did in NetBSD) from work to ingest more unpredictable data at boot time (which I also subsequently did in NetBSD). On the former score (improvement and modernization of the mechanism) I think in NetBSD we still have quite a bit of room for improvement. On the latter, I think we do about as well as anyone. A key insight for me came from Peter Gutmann: it is important to ingest data you have strong reason to believe are truly random; but it is also important to ingest data you have strong reason to believe are merely expensive and difficult for a prospective adversary to measure or predict. In the real world, the latter can often save your butt, or your customers' butts. So we eat things like the first several seconds of frames from the network; dmesg output; TOD; IP addresses; hostnames; and other configuration and nonsecret data that will vary from system to system and which an adversary would have to measure in the field rather than predicting _a priori_; as well as data like temperature, voltage, and fan speed which we know to be related to one another, but through (to again paraphrase Peter) physical processes which are very difficult to model; _plus_ the timestamps and other "TRNG" data that are the traditional food of system entropy pools. And we never, ever feed output based solely on input from a single source. If you trust your pool and output stream constructions, this approach can clearly be no worse than relying solely on timings; and in practice, I believe it is far more expensive for an adversary to attack. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Cryptanalysis of RADIUS MD5 cipher?
For at least 15 years there's been general grumbling that the MD5 based stream cipher used for confidentiality in RADIUS looks like snake oil. Given how widely used the protocol is, and the failure of various successor protocols (cute names and all -- TANGENT anyone?) I have always been surprised that the cipher seems not to have received any serious cryptanalytic attention. On the other hand I am not mathy enough to frequently read the primary literature. Does anyone know of any work that's been done on this? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On Sun, Sep 08, 2013 at 03:00:39PM +1000, James A. Donald wrote: > On 2013-09-08 1:25 PM, Thor Lancelot Simon wrote: > >On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote: > >>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. > >You know as soon as anyone complained about this, they turned around > >and provided access to the unwhitened output in the next major version > >of the same product family, right? > > I am not aware of this. Could you provide further details? http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed > And since no one needs high bandwidth true random numbers, why the > on chip whitening? Surely there was some internal discussion of > this decision? A) I don't agree with your premise. B) Are you under the misapprehension that I work for Intel? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote: > > 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. You know as soon as anyone complained about this, they turned around and provided access to the unwhitened output in the next major version of the same product family, right? > A decision that even assuming the utmost virtue on the part of the > designers, leaves open the possibility of malfunctions going > undetected. And one that echoes what about 50% of the other people who have built hardware random number generators also made. > That is a question a great many people have asked, and we have not > received any answers. No answers aside from Intel actually providing exactly what you asked for, next chance they got. > Access to the raw output would have made it possible to determine > that the random numbers were in fact generated by the physical > process described, since it is hard and would cost a lot of silicon > to simulate the various subtle offwhite characteristics of a well > described actual physical process. I am extremely skeptical of this claim. Thor ___ 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 09:05:33PM +0200, Eugen Leitl wrote: > > 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. I think you take this more than a little too far. I see CPU-integral RNGs as very valuable source to be mixed with other sources in a software pool of entropy. Why should we reject them, unless we think the mixing functions themselves are useless? The lesson here seems to me to be that we should be far more assiduous in seeking out additional sources of entropy and in always ensuring software RNGs mix input from multiple such sources into all output. We should abandon sacred cows like the notion of information-theoretic randomness (that we don't actually know how to measure, but in pursuit of which we hamstring our software RNGs by arranging that they refuse to produce any output unless, by some questionable criterion, there is enough of it) and pursue engineering goals we can actually achieve, like mixing enough other-source input, of whatever quality, with the output of fast generators we can no longer trust that the adversary must actually attack the mixing function, rather than iteratively guessing the few state bits he does not already know. Secondarily -- and sadly! -- we must now be very suspicious of devices that integrate random number generation and encryption. Can we even trust raw hardware RNG output for the generation of IVs? I would argue not, because the same device's AES engine could be leaking key bits into our explicit IVs, etc, and we couldn't ever know. Devices that offload packet processing in its entirety (SSL accellerators, IPsec accellerators, etc.) have even more opportunity to do this sort of thing. Hardware crypto offload may still be very useful -- random number generation perhaps in particular -- but we will have to apply it with extreme care, and with a deliberate eye towards eliminating covert channels put in place by people at least as smart as we are, and with far more time and experience thinking about the problem from the offensive point of view. Finally, we have to accept that the game might just be over, period. So you use a pure software RNG, mixing in RdRand output or not as you may prefer. How hard do you think it is to identify the datastructures used by that RNG if you can execute code on a coprocessor with access to host RAM? Almost every modern server has such a coprocessor built in (its management processor) and you won't find the source code to its firmware floating around. Intel even puts this functionality directly on its CPUs (Intel AMT). Rather than beating up on the guy who put a lovely RNG instruction into every processor we're likely to use any time soon, it seems to me we ought to be beating up on ourselves for ignoring far simpler and more obvious risks like this one for well over a decade. Seriously, show of hands, who here has ever really put his or her foot down and insisted that a product they were purchasing _omit_ such functionality? Not chosen not to pay for it, refused to buy server X or mainboard Y simply on the basis that management processor functionality was onboard? Now, compare to the number of people complaining about backdoored RNGs here and elsewhere on the Internet. Go figure. To me the interesting question, but one to which I don't expect to ever know the answer, is whether the adversary -- having, we can assume, identified high value devices to systematically compromise, and lower value devices to defer for later or simply ignore entirely -- went at those devices sniper-style, or shotgun-style. Were a few key opportunities for tampering identified, and one or two attempted against each targeted device? Or were a wide variety of avenues explored, and every single one that seemed relevant attempted everywhere, or at least against certain particularly high value devices? If we knew that, in a way we might know, when we did finally see concrete evidence of a particular kind of tampering, how long to keep looking for more. But we aren't going to know that, no matter how much we might want to. Attacks on crypto hardware, attacks on management processors, attacks on supervisory or trusted execution modes seldom exercised in normal system operation, attacks on flash modules holding boot code, so that under the right circumstances they replace page P with evil page P', attacks on elements of IC vendors' standard cell libraries (DMA engines would seem promising); assume the adversaries are smart, and good at their jobs, and the sky would seem to be the limit. The sky will fall, of course, when various nation-states' agencies really start digging for the holes punched in all of our security by the agencies of others (not my own observation, I should note). Too much of this stuff will become all-too-common knowledge. It's going to be quite a ride. But I see no reason to beat up on hardware random number generators *in partic
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. Not necessarily; the implementation may have been subverted instead. It's unfortunate that some have attacked you personally, or if not, then said things that came awfully close to it. However, it strikes me as naive in the extreme to think that what you designed would not constitute a prime target for tampering of exactly the kind we now know has gone on. If it wasn't such a target, either your employer did something very noble, or someone at the NSA didn't do his or her job, or the systems containing what you designed had _already_ been compromised in some way that rendered your work much less of an improvement to security than you intended it to be. Your employer could help clear this up by publically urging the news outlets that have redacted the list of companies that took payments to compromise their own product to confirm whether or not its own name is on the list. Or by offering to indemnify its customers against the effects of any such compromise, with very specific reference to each of its current products that is in any way a plausible target for such tampering. I'm not holding my breath. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Compositing Ciphers?
On Sat, Sep 07, 2013 at 02:53:22AM +0200, Natanael wrote: > http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html > Apparently it's called "cascade encryption" or "cascade encipherment", > and the implementations are apparently called "robust combiners". And > by the way, Truecrypt already lets you pick your chosen combo of AES > and two other ciphers. If you want to do this with stream ciphers, a fundamentally different approach would be to use Knuth's "Algorithm M" (Knuth, 2ed, vol.1 , p 32): Algorithm M (Randomizing by shuffling). Given methods for generating sequences (Xn) and (Yn), this algorithm will successively output the terms of a "considerably more random" sequence. We use a table V[0], V[1], ... V[k-1], where k is some number chosen for convenience, usually in the neighborhood of 100. Initially, the V-table is filled with the first k values of the X-sequence. M1. [Generate X, Y.] Set X and Y equal to the next members of the sequences (Xn) and (Yn), respectively. M2. [Extract j.] Set j <- [kY/m] where m is the modulus used in the sequence (Yn); that is, j is a random value, 0 <= j < k, determined by Y. M3 [Exchange.] Output V[j] and then set V[j] <- X. The reference proceeds to give two examples. If there are more modern (post-1981) references that agitate against this method of combining two keystream generators, I'd love to learn of them. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:33:11PM -0400, shawn wilson wrote: > On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald wrote: > > At startup, likely to be short of entropy. > > > > > If /dev/urandom seeded at startup, and then seeded no further, bad, but not > > very bad. > > > > If /dev/urandom seeded at startup from /dev/random, then should block at > > startup. > > > > If /dev/urandom never blocks, bad. Should block at startup waiting to > > receive 160 bits from /dev/random, and never block again. > > > > I don't follow this - I understand why lack of entropy should block > urandom but, why shouldn't it block on a running system that > http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On Wed, Jul 17, 2013 at 03:50:50AM -0400, William Allen Simpson wrote: > On 7/16/13 11:15 AM, Matthew Green wrote: > >http://www.isg.rhul.ac.uk/tls/RC4biases.pdf > > > Thanks for bringing this pre-print link to my attention! > > > >In summary, don't use RC4. Don't use it carelessly with IVs. And don't use > >RC4. > > > RC4 is available in many libraries and platforms. For the > immediate future, it is most easily and likely implemented. So is single-DES. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On Tue, Jul 16, 2013 at 03:23:01AM -0400, William Allen Simpson wrote: > On 6/22/13 8:24 PM, Greg Rose wrote: > > > >On Jun 22, 2013, at 15:31 , James A. Donald wrote: > > > >>On 2013-06-23 6:47 AM, Peter Maxwell wrote: > >>>I think Bernstein's Salsa20 is faster and significantly more secure than > >>>RC4, whether you'll be able to design hardware to run at line-speed is > >>>somewhat more questionable though (would be interested to know if it's > >>>possible right enough). > >> > >>I would be surprised if it is faster. > > > >Be surprised, then... almost all of the recent word- or block- oriented > >stream ciphers are faster than RC4. And NOTHING should still be using RC4; > >by today's standards it is quite insecure. > > > So I spent some (much too much) time reading old PPP archives on our > earlier discussions selecting an algorithm. Sadly, 3DES was chosen, > but rarely implemented. > > I cobbled together a draft based on old discussion for ARC4. It > surely needs more work. Although (as you mention) that's old stuff, > it has the advantage of having running code in most existing systems, > and could be rolled out quickly on high speed connections. > > http://tools.ietf.org/html/draft-simpson-ppp-arc4-00 If you're really going to publish a new RFC -- even an Experimental one -- using RC4, you should really use RC4-drop-N. For even moderately sized packets and reasonable values of N, if you effectively rekey every packet, you will end up wasting 25-50% of the throughput of the system. Conclusion: RC4 is particularly poorly suited for this application in the modern day. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Snowden: Fabricating Digital Keys?
On Tue, Jun 25, 2013 at 05:17:04PM -0400, Bill Scannell wrote: > This Daily Beast story on Causa Snowden > (http://www.thedailybeast.com/articles/2013/06/25/greenwald-snowden-s-files-are-out-there-if-anything-happens-to-him.html) > contains the following sentence: > > "Last week NSA Director Keith Alexander told the House Permanent Select > Committee on Intelligence that Snowden was able to access files inside the > NSA by fabricating digital keys that gave him access to areas he was not > allowed to visit as a low-level contractor and systems administrator. " > > How would one fabricate a digital key? Presumably using administrative access to the machinery of a certificate authority or a signing system for security assertions. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Isn't it odd that...
...despite all the attacks we've seen on compresion-before-encryption, and all the timing atatacks we've seen on encryption, and the highly data-dependent computational effort associated with compression (including in widespread, hardware-accelerated, and valuable applications like lossy video compression, where the complexity of the input, even in applications where hardware escrow of some kind hides a session key, is exposed by the encoding of the output)... ..we haven't really seen any known-plaintext key recovery attacks facilitated by timing analysis of compressors applied prior to encryption? -- Thor Lancelot Simon t...@panix.com It's very complicated. It's very cumbersome. There's a lot of numbers involved with it. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] So, PKI lets know who we're doing business with?
On Tue, Jan 08, 2013 at 05:06:23PM -0500, Jeffrey Walton wrote: > On Tue, Jan 8, 2013 at 3:59 PM, Thor Lancelot Simon wrote: > > > https://www203.americanexpress.com > > That's not too egregious (though its bad). What frustrates me is when > they send you to a different domain for the authentication or a > transaction. Well, yes, that's bad, but of course what I was trying to point out as bad in this particular case was that even in the face of an hour's worth of effort by someone calling from the security department of another institution, in this case, the purported holder of this certificate was *unable to say* whether it was actually theirs or not. Whoops. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] So, PKI lets know who we're doing business with?
What do you do if even they don't know? Today I tried to help someone who was mid-transaction on Amex's cardholder web site, associating a new card with their account, when the next step of their process hopped us over to https://www203.americanexpress.com. Which has an EV certificate from VeriSign that's been expired since October last year. Of course this is more likely due to error than malfeasance, but nonetheless. It's what it would look like, eventually, if an attacker stole a private key just once, right? So this isn't something you want to go typing your financial secrets into. Approximately an hour on the phone with American Express produced approximately as much head-scratching among Amex employees as on my end. An expired certificate for a back-end server isn't among the problems their online services help desk knows how to test for nor can report. Their fraud protection department refers all complaints of web site misbehavior, even security-related, to their online services help desk. Their high-limit corporate card support team can create tickets in their web development queue but evidently does not have contact information for any relevant security department at American Express. The technical contacts for their domain don't answer the phone. In other words, even *they* don't know if the certificate in question really vouches for them or not, and don't have any way to find out. Can we really expect that end users will ever get that decision right? Sure. Sure we can. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Devices and protocols that require PKCS 1.5 padding
On Mon, Jul 02, 2012 at 01:26:20PM -0400, Matthew Green wrote: > > More generally, padding oracle attacks exist against OAEP as well > (Manger's attack). In practice you typically have to construct the > oracle by measuring a timing differential in the decryption process. > That's hard over a network, but if you're directly attached to the > device and have a cycle-accurate timer at your disposal, maybe not. > > These devices are slow! Indeed they are. And they are part of a class of slow devices that, of course, includes not just so-called OTP tokens that have smartcard functionality, but pure smartcards and their close cousins TPM chips. I am in particular worried about protocols like OpenPGP, which *require* version 1.5 padding and which are often used with these kinds of devices by the security conscious on the theory that security is thereby improved. Where these protocols can't be changed I suppose the only real countermeasure is fairly draconian blinding implemented in software around all the hardware implementations of RSA operations with v1.5 padding. Besides PGP, what other standard, widely-deployed protocols require the use of padding types other than OAEP? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Tue, Jun 19, 2012 at 07:35:03PM -0700, coderman wrote: > > is there any literature on the typical failure modes of TRNG/entropy > sources in deployed systems? > > my understanding is that they tend to fail catastrophically, in a way > easily detected by FIPS sanity checks. E.g. clearly broken. I know of one case in which a design mistake may have caused related bits to be output. I think the FIPS statistical tests might have turned it up, but the continuous-output test might well not have. This was a design by Hifn where they reused an existing RNG block but changed the output LFSR and thus had to rework the interface to register exposed to the PCI bus in which they reported results. They left out a latch, so you could accidentally get the same bits from the LFSR twice or get an intermediate state where some bits were from the previous state and some were fresh. The COT would have caught the former, but given the clocks involved the former case would have been very, very unlikely. It would not have caught the latter. I never got a clear answer from Hifn whether they actually left the latch out of the silicon or just out of the documentation. However, I tried very hard to give them opportunities to tell me it was just the docs that were wrong, and they didn't. The workaround was to simply read the register repeatedly, discarding results, until one knew all the bits had to be fresh given the other clocks involved; inefficient, but it got the job done. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Mon, Jun 18, 2012 at 09:58:59PM -0700, coderman wrote: > > this is very useful to have in some configurations (not just testing). > for example: a user space entropy daemon consuming raw, biased, > un-whitened, full throughput bits of lower entropy density which is > run through sanity checks, entropy estimates, and other vetting before > mixing/obscuring state, and feeding into host or application entropy > pools. Sanity checks, entropy estimates, and other vetting *which the output of a DRBG keyed in a known way by your adversary will pass without a hint of trouble*. It seems to me the only reason you'd benefit from access to the raw source would be if you believed Intel might have goofed the sanity checks. For my part, I am happy to rely on CRI's assurance that Intel's sanity checks are good. The only defense against a deliberately compromised hardware RNG is to mix it with something else. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Microsoft Sub-CA used in malware signing
On Tue, Jun 12, 2012 at 10:51:59AM -0500, Marsh Ray wrote: > > What is unclear is if there are any effective costs or rate > limitations on how often one can 'activate' an MSTS license server. > A compute cluster faster than 200 PS3s could cut down on the number > of license certs that were burned to make the attack work. One wonders what Microsoft knows about who requested all those licenses. Presumably there was some effort put into plausible deniability. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Microsoft Sub-CA used in malware signing
On Mon, Jun 04, 2012 at 10:20:33AM +0200, Erwann Abalea wrote: > It's also not clear about what could have been done with TS certificates. > Is it only codesigning, or TLS server as well? I'm surprised they can be used for code signing at all. TS (in its modern incarnation) is a TLS-encapsulated protocol. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years
On Wed, May 02, 2012 at 02:23:47AM +1200, Peter Gutmann wrote: > Thor Lancelot Simon writes: > > >NIST says 2048 bit RSA keys should have a 3 year lifetime. Who here really > >wants to explain to customers (or investors!) that he willfully ignored that > >recommendation and just reused the same old key when making the CSR for that > >new certificate? > > This is standard practice in a significant chunk of the industry, to the > extent that "renew a certificate" means "get the same key recertified". You > don't "wilfully ignore NIST recommendations", you click on "renew > certificate". Dealing with cert rollover is painful enough already without > having to try and find PKI documents you've never heard of telling you what to > do. I wouldn't call SP800-57 a "PKI document". Though I might call it "an eminently reasonable and comprehensive document with certain ill considered sections bolted on as a sop to the PKI crowd". Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years
On Tue, Apr 24, 2012 at 12:07:33PM -0500, Nico Williams wrote: > On Tue, Apr 24, 2012 at 11:20 AM, Marsh Ray wrote: > > On 04/23/2012 08:47 PM, Peter Maxwell wrote: > > I look at it this way: > > > > * Revocation is junk. It doesn't work. It especially doesn't work when an > > attacker wants it not to work. > > > > It is so broken that Chrome isn't even going to bother with OCSP checking > > anymore: > > http://www.imperialviolet.org/2012/02/05/crlsets.html > > But this too is revocation. > > Assuming some revocation scheme works at all, then longer lived certs > merely increase the size of the revocation database. This is at least > obnoxious. > > If no revocation scheme works then the only revocation mechanism left > is certificate expiry. Until now no revocation mechanism has worked > well or universally, so shorter certificate lifetimes are better. > > That said, short certificate lifetimes do nothing to mitigate > undetected private key compromises when the new certificates have the > same subject public key as the ones they replace. That said, those who follow the relevant NIST recommendations will not do that (reuse keys when writing new certs). The recommendations on cryptoperiod are with regard to keys, with a recommendation per algorithm, and though there are many ugly holes punched in the standard for commercial PKI implementations, I do not see one that would allow writing a new cert with an old key if the old key is past its allowed cryptoperiod. NIST says 2048 bit RSA keys should have a 3 year lifetime. Who here really wants to explain to customers (or investors!) that he willfully ignored that recommendation and just reused the same old key when making the CSR for that new certificate? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin in endgame
On Sat, Feb 25, 2012 at 05:08:44AM +1000, James A. Donald wrote: > If the users of bitcoin are primarily criminals, that is pretty much > what the founders intended. Every middle class man of affairs and > business commits three felonies a day. > > The paper presupposes that criminals are such horrible people that > everything they touch turns to shit. > > My experience is that ordinary unorganized criminals are anti social > and need killing, but that organized crime is pretty good, or at > least not nearly so bad police and regulatory authorities. Is the major purpose of this mailing list really the discussion of political and social theory? I thought I had subscribed to cryptography@randombit.net, not "I already spent four years doing political science, thanks." Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Sat, Feb 18, 2012 at 12:57:30PM -0500, Jeffrey I. Schiller wrote: > > The problem is that ssh-keygen uses /dev/urandom and it should really > use /dev/random. I suspect that once upon a time it may have (I don't > have the history off hand) and someone got annoyed when it blocked and > "solved" the problem. Um, why would it ever _unblock_, on such a device under typical first-boot conditions? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
On Tue, Feb 14, 2012 at 09:35:45PM +0100, Ralph Holz wrote: > > As Crossbear's assessment is not something everyday users will > understand, we ourselves view Crossbear as the tool that, e.g., a > travelling security afficionado/hacker/interested person might want to > use, but not your average guy. Our goal is to find out how many Mitm > actually happen, and how, and where. That's why Crossbear has this > second component, the hunting tasks. Interesting -- will this work, in the case of authorized MITM of the network the client's on? The second SSL connection will always fail, since the MITM device will MITM it. Perhaps there should be an option to retrieve results separately and later? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
On Tue, Feb 14, 2012 at 09:13:11PM +0100, Ralph Holz wrote: > > > It is not so hard really to see the conceptual difference between the two > > cases. But to tools like Crossbear, they basically look the same. > > Why? Crossbear sends the full certificate chain it sees to the CB > server, where it is compared with the full chain that the CB server sees > (plus a few more servers, too, actually, that it can ask). Convergence, > AFAICT, does the same. If you're inside the corporate network, the > certificate chain in the SSL handshake cannot be the same, and both > systems will detect them. In both cases, Crossbear will detect a MITM device, yes? But in one case, the device is authorized to sign for the entities it's signing certificates for, and in the other, it's not. This does not in any way diminish the usefulness of Crossbear as a tool for detecting MITM devices. But what's interesting about what happens in these two cases is that it's _whether the user is being deceived_ that differs. Crossbear can't know that -- the user has to supply the knowledge of whether there is, in fact, an authorized MITM in place. And that is precisely what is wrong with what Trustwave did: they tried to make it look like there was no MITM in place instead of an unauthorized one, where in this case "authorized" means "the administrator of the client node positively agreed to have that node's traffic MITMed". Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
On Tue, Feb 14, 2012 at 03:51:16PM +0100, Ralph Holz wrote: > Hi, > > > Well I am not sure how they can hope to go very far underground. Any and > > all users on their internal network could easily detect and anonymously > > report the mitm cert for some public web site with out any significant risk > > of it being tracked back to them. Game over. So removal of one CA from a > > major browser like mozilla would pretty much end this practice if it is > > true > > that any CAs other than trustwave actually did this... > > If all users used a tool like Crossbear that does automatic reporting, > yes. Not really -- and this I think goes to the root of why what was done here is so evil. It is common practice on many networks in certain industries to deploy SSL MITM devices which terminate, decrypt, examine, and reencrypt all traffic. However, the usual way to do this is to generate a new CA certificate for the MITM device and load it into all the systems expected to be connected to the network in question as a trusted root. In this case, the owner of the network has chosen, by policy, to not allow devices to perform SSL unless they trust the network's own CA, and that CA has an effective policy which expressly allows it to facilitate MITM of SSL traffic. I do not find this unreasonable for certain environments, and if users choose to bring their private devices onto those networks, they have to take a positive step to facilitate this examination of their traffic -- they have to install the MITM CA's certificate as a trusted root. But what Trustwave did is very, very different. They sold a sub-root that seems almost tailor-made to deceive users into thinking that MITM was *not* taking place. After all, if the intent were not to deceive the network's users, the usual solution (where the client node's administrator must accept the MITM device's CA) would have sufficed. If the intent was not (primarily) to deceive but rather to allow MITM device deployment with less administrative hassle, I can say only these things: A) It might be easier for me to get petty cash for my legitimate business purposes by mugging people in the street than by filling out corporate paperwork but that does not make it OK to mug people in the street. B) If we are to believe Trustwave's claims about how they secured and audited the device on which this CA's keys were stored, is it really plausible that this was done for ease of administration, compared to the "standard" solution? It is not so hard really to see the conceptual difference between the two cases. But to tools like Crossbear, they basically look the same. Bad, bad, bad. Thor P.S. If one really wanted to know what CAs were in the business of selling these, one might try using any leverage one had handy to press the manufacturers of the MITM devices, who very likely know because their support or engineering personnel will have seen it in the field. I can think of some pretty simple ways Mozilla could seek to obtain this information from the device manufacturers, if Mozilla wanted to play hardball. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "folded" SHA1 vs HMAC for entropy extraction
On Thu, Jan 05, 2012 at 05:51:57PM -0600, Marsh Ray wrote: > On 01/05/2012 03:46 PM, Thor Lancelot Simon wrote: > >I am asking whether the > >use of HMAC with two different, well known keys, one for each purpose, > >is better or worse than using the "folded" output of a single SHA > >invocation for one purpose and the unfolded output of that same > >invocation for the other. > > But you don't need HMAC for this, HMAC's properties are evaluated > for authentication. > > What this usage needs is a tweakable one-way compression function. > Like, say, a hash function with a different fixed input prefix for > each operation. Having your tweak values a fixed size is a good > idea. > > HMAC is doing something similar, but using the secret key as the > prefix. It expands the secret to the same size as the hash > function's input block (usually 512 bits). Having them take up a > whole input block might improve performance a little in some > implementations because the intermediate state you have to store is > smaller and in this case it could even be compile-time constant. FWIW, using HMAC like this is the "extract" step of the two-step extract-expand HMAC based construction that is HKDF: http://tools.ietf.org/html/draft-krawczyk-hkdf-01 HMAC does have some other desirable properties that the raw hash functions do not, no? I thought HMAC met the strict avalanche criterion, while SHA1 does not, and that this was one of the reasons why truncation of HMAC results was considered safer than truncation of raw hash results. In this application, the result will often be truncated when it is used, which is another reason why I -- naive crypto-plumber though I am -- thought HMAC might be a better choice. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "folded" SHA1 vs HMAC for entropy extraction
On Fri, Jan 06, 2012 at 07:59:30AM +1100, ianG wrote: > > The way I treat this problem is that it is analogous to inventing > ones own algorithm. From that perspective, one can ask: What is? The "folded" SHA, or the use of HMAC? You do understand why it's important to obscure what's mixed back in, I assume. If not, read the paper I referenced on the Linux RNG; by insufficently obscuring what went back into the pool, the implementors made an attack with only 2^64 complexity possible. With the constraint that you can't just output exactly what you mix back in, a plain hash function without some further transformation won't suffice, whether it's MD4 or SHA512. I am asking whether the use of HMAC with two different, well known keys, one for each purpose, is better or worse than using the "folded" output of a single SHA invocation for one purpose and the unfolded output of that same invocation for the other. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "folded" SHA1 vs HMAC for entropy extraction
On Thu, Jan 05, 2012 at 12:45:14PM +1300, Peter Gutmann wrote: > Thor Lancelot Simon writes: > > >However, while looking at it I have been wondering why something simpler and > >better analyzed than the "folded" SHA should not be used. > > Folding the output is belt-and-suspenders security, it denies an attacker > direct access to the raw output of whatever the last stage of processing > (3DES/AES/SHA1/HMAC-xxx/whatever) is. For example my generator is designed on > the basis that any part of it should be able to fail completely (replacing a > crypto step with memcpy() or using all-zero keys) without it affecting the > security of the overall design, and to do that you need a lot of redundant > security. Sure, using HMAC is cryptographically sound, but what happens if > your HMAC key is compromised, or an attacker can glitch the hashing operation, > or something else goes wrong? I'm proposing to use HMAC with two different, non-secret keys: one to generate the data supplied to the output stage, one to generate the data mixed back in. It seems to me this uses the same number of invocations of the hash function per output byte, and, unless I'm missing something, the "folding" surely isn't _more_ secure. Am I missing something? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] "folded" SHA1 vs HMAC for entropy extraction
I'm working on the entropy-pool code in NetBSD, which began its life many years ago as a simplified implementation of the same ideas behind the Linux /dev/random implementation. The NetBSD implementation now keys a stream generator from the pool rather than directly outputting pool bits, but the underlying entropy gathering and mixing model is basically the same -- a very large LFSR using SHA1 to "distill" entropy on output. Eventually I will replace it with a multi-pool implementation like Fortuna. However, I'm trying to make incremental improvements while waiting for that mythical great extent of free time to appear. One thing that's always bothered me has been the use of an odd "folded" SHA1 construct to generate output bits. What is done is this: The pool is 4096 bits long. It is hashed with SHA1, producing S1. S1 is split in half, the first 80 bits and last 80 bits, producing H1 and H2. H1 xor H2 is computed to produce R, which is returned to the caller. S1 is mixed back into the entropy pool as input. The Linux code had a weakness in this area which is described by Gutterman, Pinkas, and Reinman's paper from 2006. I don't believe the NetBSD code has this problem. However, while looking at it I have been wondering why something simpler and better analyzed than the "folded" SHA should not be used. In particular, I do not see why HMAC with different, known keys should not be used: The pool is 4096 bits long. HMAC(K1, pool) is computed, producing R, which is returned to the caller. HMAC(K2, pool) is computed and mixed back into the entropy pool as input. I would appreciate comments on this general idea. -- Thor Lancelot Simont...@panix.com "All of my opinions are consistent, but I cannot present them all at once."-Jean-Jacques Rousseau, On The Social Contract ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] CAPTCHA as a Security System?
On Tue, Jan 03, 2012 at 01:57:10AM -0500, Randall Webmail wrote: > > There is one girl (and it is always a girl) who is at the control center. > She comes to the checkout station to override the system when the shopper > scans beer. No one watches to see if you scan every item in your cart. > Most people don't steal, and it's cheaper for Wal*Mart to allow the thieves > to ply their trade than it is to put $8.00/hour girls in place to (mostly) > stop those who do. You have more faith in human nature (or perhaps a considerably less sophisticated understanding of the costs of inventory shrinkage) than Walmart does. Look up. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] How are expired code-signing certs revoked?
On Fri, Dec 09, 2011 at 01:01:05PM -0800, Jon Callas wrote: > > > If you have a certificate issue a revocation for itself, there is an obvious, > correct interpretation. That interpretation is what Michael Heyman said, and > what OpenPGP does. That certificate is revoked and any subordinate > certificates are also implicitly revoked. It's also like making a CRL for > everything you issued. Indeed. Non-temporal logic is a very poor substitute for temporal logic in any real-world situation. But some simple definitions should make the matter clear in any event: Q: When is a certificate valid? A: Until it is revoked, and if some other conditions are met. Q: When is a certificate revoked? A: At any time AFTER an authorized party revokes the certificate. Q: Who is an authorized party for the purpose of revoking a certificate? A: The signer of the certificate* * one can envision systems in which the rule is "...or the party identified by the certificate", too, but when talking about PKI, generally, that is not the rule that is used. Fortunately self-signed certs let us reason about this issue in a vacuum. Now the problem degenerates to the basic quarrel over retroactive revocations. But, depending what your norms are there, with appropriate choice of a temporal frame of reference it's no harder to solve. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Thu, Oct 27, 2011 at 12:15:32PM +0300, Martin Paljak wrote: > > You have not described your requirements (ops/sec, FIPS/CC etc) but if > the volume is low, you could take USB CryptoStick(s) > (crypto-stick.org), which is supported by GnuPG and what can do up to > 4096 bit onboard keys, unfortunately only one signature/decryption > pair usable through GnuPG. Probably you can also stack them up and > populate with the same key for load sharing. So this appears to be basically a smartcard and USB smartcard reader built into the same frob. I can probably find a way to put it within the chassis of even a fairly compact rackmount server without fear it will come loose and take the application offline. Unfortunately, it also appears to be unbuyable. I tried all three sources listed on the crypto-stick.org website yesterday: two were out of stock, while the third said something along the lines of "low stock - order soon", walked me through the whole ordering process, then said my order had been submitted -- without ever asking for payment. It's possible I might walk into my office next week and see two crypto-sticks, provided free of charge, but I am not too optimistic about that! Is there a way to actually get these? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] -currently available- crypto cards with onboard key storage
I find myself needing a crypto card, preferably PCIe, with onboard key storage. The application is PGP, so I really need hardware that can use keys stored onboard to do arbitrary RSA operations -- rather than a protocol accellerator which can use onboard keys only to do more complex operations that happen to include RSA signing or encryption as one step. As far as I know, the only current products that do this are the IBM 4765 and the BCM586x line of chips. There were more sources once-upon-a-time of course -- nCipher and NetOctave/NBMK/etc. but those products seem to be gone now (and have obsolete PCI host interfaces, as well). I cannot actually find a card with a BCM586x on it, and there is a suspicious absence of pricing and availability information on those parts from the usual IC distributors' web sites as well. What, if anything, can I buy off-the-shelf in this space? I don't think a smartcard will work, since I need unattended operation within the chassis of a standard x86 rackmount server. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
