[Discuss] What key lengths are currently adequate?
OK, I'm not looking for entropy anymore. I just found an old key. It doesn't expire until 2017, so I don't think I have to generate a new one. Here's another question, though: what key lengths are considered adequate these days? This key is 4096 bits, which I'm confident is long enough for now, but I'm curious what the minimum recommended key length is these days. Bill -- Bill Horne William Warren Consulting 339-364-8487___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
Does GPG use /dev/random? I think so... On my current Linux installation, Debian 7, my pool size is 4096-bits, and my last couple Ubuntus were I think the same. That is a lot. A public key of 4096-bits is like a much shorter symmetric key (~200-bits?), so unless you are generating a bunch of keys, you shouldn't have any problem. The entropy accounting in the kernel is very conservative, and it is an inherently impossible task unless one can precisely characterize the source and the kernel can't. By the time GPG is happy with with the entropy it has drawn, you should be perfectly fine. (Assuming GPG doesn't have some other vulnerability. But is has to be bug free, right?) As for sources of entropy, this has been a moving target. For a while the urandom maintainer was removing every source of entropy he couldn't characterize, which means he was removing nearly everything, which was stupid. More recently sanity as reigned and the idea is that stirring the entropy pool is always a good idea, even with predictable data, so numbers of entropy sources are increasing. But who knows which policy is in your current kernel? In any event, wiggling the mouse and typing stuff has always been used as an entropy source. Drifting off topic, one of my arguments is that on a fast x86 machine where the timestamp counter is running at a GHz-plus rate, and every time an interrupt comes in the count can be sampled and the lowest order bits will contain some entropy. Why? Because a GHz-plus clock is really fast, it is hard to know the precise value of such a clock at any distance--that's why computer hardware doesn't try to distribute that fast a clock any distance, the skew gets too much for synchronous circuits to function. So if you are running a sane kernel and the ethernet driver interrupts are used as an entropy source, just receiving a packet with generate real entropy. (Unfortunately, ARM chips don't have such a high speed counter. Getting entropy off a counter of just a few hundred megahertz isn't as good. It is much easier to know that at a greater distance.) -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] What key lengths are currently adequate?
On 09/07/2014 01:59 AM, Bill Horne wrote: OK, I'm not looking for entropy anymore. I just found an old key. It doesn't expire until 2017, so I don't think I have to generate a new one. You can always change the expiry, so that shouldn't be what stops you using the key. Here's another question, though: what key lengths are considered adequate these days? This key is 4096 bits, which I'm confident is long enough for now, but I'm curious what the minimum recommended key length is these days. 2048 bit RSA is considered the minimum. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Bill Horne Is there any way to speed the process? Short of putting up an antenna and counting bits of static, how can I accumulate random bits more quickly that by typing or moving the mouse? Yes, you can read random bits from a bunch of other machines, download from online entropy sources and so forth, use http://tinhatrandom.org, there's a nice windows app (I wrote) to collect mouse entropy on a windows machine, etc... There's also a list of online entropy sources. Write to /dev/random You mentioned in another email, that somebody suggested reading /dev/random and dumping to /dev/null. This is exactly the opposite of correct and demonstrates the person who said it, to have no clue what they're talking about (or else they have a clue and they're being dicks for the sake of undermining your system security). The more you read from /dev/random, the more you *reduce* the available entropy in your system entropy pool. I *believe* (but haven't tested or otherwise confirmed) that the linux kernel honors bits written to /dev/random. Also, shutdown into BIOS, and make sure your TPM is enabled. Even if you use it for nothing, it is a hardware entropy source that the kernel can source from. Keep your system busy, reading from disk and so forth, moving your mouse around, keyboard entry, network activity... All are used as entropy sources. (Unless you built your own kernel and failed to include entropy sources). ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] What key lengths are currently adequate?
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Bill Horne This key is 4096 bits, which I'm confident is long enough for now, but I'm curious what the minimum recommended key length is these days. The cryptographic strength should be at least 128, preferably 256. For estimating cryptographic strength of various keysizes (including RSA 4096), see here: http://grouper.ieee.org/groups/1619/email-3/pdfnnOaPiCVTm.pdf In RSA, they keysize grows relative to the square of the cryptographic strength, and unfortunately, so does the computation cost. RSA 1024 ~= 80 (insufficient in present day) RSA 2048 ~= 112 (still good enough for most purposes, for a little while longer) RSA 3072 ~= 128 (good) RSA 4096 ~= 128 (pointless but fine) RSA 16k ~= 256 (computationally impractical to use) Basically in RSA, 3072 is the last useful level for RSA. Because 4096 doesn't add significantly more strength, and by the time you get up to 16k, the processing time becomes prohibitive (like half an hour to generate a key, 1 minute to encrypt a packet, etc). We are currently in the last days of RSA being useful. Next up: ECC. By the way, I'm exaggerating the performance problems of RSA 16k, but it does literally take 7-30 minutes to generate a key. In ECC, the cryptographic strength is equal to about half the ECC key size. And ECC is way, way, way, way, way faster than RSA. Like, use any size key, and both key generation and use will all be measured in ms. (Might be hundreds of ms for the largest operations, but still, that's compared to half an hour to do the equivalent operation in RSA). Strangely, the ECC key sizes are 256, 384, and 521. (That's not a type-o, I meant 521 not 512.) So the crypto strengths are: ECC 256 ~= 128 ECC 384 ~= 192 ECC 521 ~= 260 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Bill Horne With the key signing coming up, I set out to generate a brand new, 4096-bit RSA key. However, GPG says I need more entropy, BTW, how are you generating your key? Because knowing what I know now, the only thing I trust anymore is to use tinhatrandom as the random source, and use BouncyCastle to generate the RSA key based on that random source. But this would be rather low-level programatic. Another, easier approach I would trust is: First of all, verify that you know where openssl stores its seed. ls ~/.rnd It exists? Good, that's probably it. rm ~/.rnd openssl genrsa -out private.pem 3072 rm private.pem ls ~/.rnd It exists again? Good, that means your openssl command regenerated it, so you've definitely found your .rnd file You can simply append randomness onto that file. Collect random bytes from other computers, using tinhatrandom, etc, and append those bytes onto the ~/.rnd file. And then generate an RSA 3072 key. openssl genrsa -out private.pem 3072 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] What key lengths are currently adequate?
On Sun, Sep 7, 2014 at 10:48 AM, Edward Ned Harvey (blu) b...@nedharvey.com wrote: 3072 Ned is (nearly) spot on. I was planning to post the following anyway soon - *Current recommended key sizes.* RSA. 1024 is obsolete. 2048 is barely ok for short term use especially with legacy devices, 3072 is currently acceptable, but for long expiration, 4096 is now recommended. Because 4096 doesn't add significantly more strength, Not exactly right, only approximately true today. These equivalences are date specific and rounded. At current factoring speed, 3072 and 4096 have respective equivalent symmetric strengths that *round down* to the same power of 2 = 128. (Unlike between 56 and 128 they don't bother with values between 128 and 256, since 256 is the holy grail value. Might be useful but ...they don't. sometimes.) As Moore's Law grinds on and number theorists continue to tune factoring shortcuts, 3072 bit RSA will drop below 128 equivalent symmetric bit strength much sooner than 4096 will. So new keys generated today for long-term use should be 4096, but 3072 is effectively as good today so no urgency to upgrade from a 3k key to a 4k key yet. *sources.* http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits NIST SP 800-131A. For Signature (only) DSA: |p| ≥ 2048 and |q| ≥ 224 ; RSA: |n| ≥ 2048 ; ECC: |n| ≥ 224 (these are stronger than RSA Lab recommended http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/key-size.htm since time has passed. Note that RSA2048 is still ok for signing but for secrecy it's legacy-use-only.) Note on cipher suites. SHA-1 no longer acceptable for DSA (exc legacy), but *is* acceptable for other uses*. *[ “HMAC, Key Derivation Functions (KDFs), Random Number Generation (RNGs and RBGs), and hash-only applications (e.g., hashing passwords and using SHA-1 to compute a checksum”.] Note that ECC is only in GNUPG 2.1 Beta but not in 2.0 Prod. :-( But you can create an ECC key now and start getting sigs on it, even if you can't yet rely on it as your primary key. [ Note. GPG's ECC is *not* affected by the presumed backdoor in Dual_EC_DRBG in FIPS 182-2 TLS. Same underlying EC Maths but, Different curves, Different use. ] -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
On Sun, Sep 7, 2014 at 8:52 AM, Kent Borg kentb...@borg.org wrote: A public key of 4096-bits is like a much shorter symmetric key (~200-bits?), so unless you are generating a bunch of keys, you shouldn't have any problem. An RSA key of size 4096 bits has *security* equivalent somewhere between 128 and 200 bits (which sometimes gets rounded down to 128 since 256 bits), but that is *not* a measure of how much entropy its generation will consume. Generating two 2kbit primes will consume a *lot* of entropy from /dev/random, because each random candidate-prime must be tested by hundreds of random 'witness' numbers (potentially upto 1kbit in size). Generating one 256bit random symmetric key would be far far more efficient in terms of entropy consumed, but that doesn't get you all the key management and authentication benefits of Public Key. (Generating RSA keys on a virtual box could be very very slow as they don't have hardware entropy sources available.) -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] mail config
Guys, On my path to a well administered home server system, I'm now down in the weeks of mail configuration. I'm using postfix since it seems to be the better alternative to sendmail. the configuration I have is basically a server which has a static IP address on the Internet. And behind the server is my local 192.168.1.0/24 network I have in my house. My desktop sits on the 192.168.1.0/24 network, while my basement server has two interfaces, one to the 192.168.1.0/24 network and the other sits on the wide open internet. I've got my mail server set up OK on the basement server, but its my office desktop that's the issue. When I e-mail myself from any account on my office desktop, (I use luxsci.com as my e-mail service), luxsci bounces the message because there is no record for my local desktop host/domain name. I can set up postfix so that it will put stephenadler.net (my basement server) as the domain from which the e-mail came, but when I read my e-mail, I can't tell if the e-mail originated from my desktop of my basement server. So, is there a way to keep the to field with the host name of my office desktop and somehow tell luxsci mail servers that my e-mail came from my basement server (stephenadler.net)? Or perhaps the better question to ask is what's the standard or most common way of setting up postfix on a system which sits behind a NAT firewall. thanks. Steve. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
On 09/07/2014 12:38 PM, Bill Ricker wrote: An RSA key of size 4096 bits has *security* equivalent somewhere between 128 and 200 bits (which sometimes gets rounded down to 128 since 256 bits), but that is *not* a measure of how much entropy its generation will consume. Generating two 2kbit primes will consume a *lot* of entropy from /dev/random, because each random candidate-prime must be tested by hundreds of random 'witness' numbers (potentially upto 1kbit in size). Oops. -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
On 09/07/2014 10:25 AM, Edward Ned Harvey (blu) wrote: Also, shutdown into BIOS, and make sure your TPM is enabled. Even if you use it for nothing, it is a hardware entropy source that the kernel can source from. As I said, urandom driver details change, but last I looked the Intel RNG is only Xor-ed into the urandom driver's output. It can't hurt--even if the NSA knows every bit it ever outputs--and it might help (maybe the NSA slips some in tracking your RNG hardware's state). But it won't help you with your entropy accounting, it is not credited to the pool. Actually, I think the detail of how they use Intel's RNG changed, but it isn't being trusted. It is only a can't-hurt extra in the mix. (When the Snowden stuff came down, Ted T'so, the original and recent urandom guy, was very relieved that, despite pressure, he didn't accept Intel's RNG output on faith.) -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
On Sun, Sep 7, 2014 at 2:01 PM, Kent Borg kentb...@borg.org wrote: Generating two 2kbit primes will consume a *lot* of entropy from /dev/random, because each random candidate-prime must be tested by hundreds of random 'witness' numbers (potentially upto 1kbit in size). Oops. Yup. Generating large crypto-grade random primes is not something you want to do frequently (as in, during a connection/transmission protocol). They should last years, and are used to protect just-big-enough temporary keys that use entropy VERY efficiently. But as frequently as you attend a PGP/GPG key-signing, bit efficiency is rather less relevant than gas mileage to get there. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] How do I add entropy?
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg As I said, urandom driver details change, but last I looked the Intel RNG is only Xor-ed into the urandom driver's output. It can't hurt--even if the NSA knows every bit it ever outputs--and it might help (maybe the NSA slips some in tracking your RNG hardware's state). But it won't help you with your entropy accounting, it is not credited to the pool. Actually, I think the detail of how they use Intel's RNG changed, but it isn't being trusted. It is only a can't-hurt extra in the mix. (When the Snowden stuff came down, Ted T'so, the original and recent urandom guy, was very relieved that, despite pressure, he didn't accept Intel's RNG output on faith.) Uh oh. A lot of the above is either inaccurate or misleading - because it appears, you've been misled and fell for it. I've studied this very specific topic a lot for the purposes of creating tinhatrandom. First and foremost, before addressing the simple facts of whether or not the XOR can be harmful, there's a bigger issue, which goes like this: You said it isn't being trusted. This is the opposite of true. If it weren't being trusted, it would be fed into the entropy pool just like everything else, so it would then be forced through all the mixing hashing algorithms in order to eliminate the untrusted entropy source's ability to maliciously manipulate the output in a controlled way. Specifically by bypassing the pool and getting XOR'd with the output, it *is* being trusted to be non-malicious. (See below). Ted T'so's comment was I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction. In this comment, he's the tail wagging the dog. He's creating the soundbite I resisted pressure from Intel, but at the same time, *what* he resisted pressure to wasn't sufficient. Yes they resisted eliminating all the other entropy sources. (Did you ever hear that Intel pressured them to rely *exclusively* on RDRAND and eliminate all the other entropy sources? I guess it must have been private conversation.) No, they didn't resist giving Intel the ability to completely undermine the other entropy sources. (Again, as explained below). The bigger problem than the XOR problem, is the undermining by Linus and mishandling of community review or community contribution. First, Matt Mackall (the other random guy) strenuously objected to Intel's patches, which Linus accepted over his insistent complaints, and caused Matt to quit in protest. Later, Kyle Condon (a little guy on the internet) wrote an open letter to Linus begging him to undo the RDRAND XOR code, supported by a copy of random.c with added comments identifying what the security problems are. Linus responded in a bully-ish meanspirited way which not only didn't address any of the technical concerns, but just launched into a tyrade of a bunch of personal insults, including Go read random.c which tends to suggest either Linus is insane, or didn't bother reading the complaint. The original petition was withdrawn, tail between the legs (got #rekt by the big famous powerful bully who maintains ultimate decision making power over the code, who entrenched himself into a position so deeply there's no hope of ever getting him back out of it). And for some reason, the media basically accepted that as a conclusion. (Which is journalistically embarrassing.) It's as if some little guy on the internet got on CNN to expose a huge safety flaw in a major car manufacturer, and then the manufacturer's spokesperson launched into a bunch of foul language insults, and then it was case closed. Bully wins. The actual fact of the matter, as I described on http://tinhatrandom.org is that if you receive two supposedly random numbers from Random Source A, and Random Source B, and you're going to just mix them together with XOR, then you definitely have a security problem if *either* A or B is a malicious adversary. The most obvious way to demonstrate this is as follows: Suppose Source A gathers entropy from mouse movements and delivers those bytes to you, claiming these are random bytes. Now suppose Source B is a malicious adversary, who also gathers entropy from mouse movements, and delivers the same exact output as Source A, because Source B knows, when you XOR those together, you're going to get all zeros as your output, which is clearly very non-random. The malicious entity could do much more clever stuff, much less obviously detectable, which would have the effect of having absolute control over the resultant random output. The malicious entity could very easily reduce every 128 bits of entropy to 16 bits (or any other arbitrary strength). The result would still appear to be random, would pass all random analysis tests, and basically be undetectable except by the
[Discuss] OT: cartoon about cryptography
http://www.smbc-comics.com/?id=3296#comic -- John Abreau / Executive Director, Boston Linux Unix Email: abre...@gmail.com / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
