Question about key size (Was: [ale] ALE PGP Keysigning PartyInstructions)

[Chris Ricker]

On Wed, 15 Jan 2003 greg at turnstep.com wrote:

> --[PinePGP]--------------------------------------------------[begin]--
> 
> > No, it *is* the point. Encryption's a pain. Keys are a pain. The 
> > longer they are, the more painful they are. Going over 2048 bits 
> > isn't supported by many common clients that end users use.
> 
> Really? What clients would this be?

pgp 2.x and all derivatives have issues interoperating with openpgp
compliant / semi-compliant implementations (gpg, pgp 5.x+) when you get over
2048-bits

> > Longer keys are markedly slower (doesn't matter to you on your 
> > desktop, but it does matter to me when I do email on my 
> > Zaurus). etc.
> 
> I think you overstate the problems. Even a Zaurus should be able 
> to handle >2048 without a problem. Using ElGamal keys, on the 
> other hand, does produce a major slowdown, but that is an 
> algorithm decision, not a key size one.

I have a zaurus. Large keys are unusably slow (and small keys only
tolerable). Lack of fp + lack of random == bad idea. As a result, I don't do
any encryption on that thing beyond WEP.

> > 1. you don't encrypt something that's worth, say $1 million to 
> > decrypt (amortizing $1 billion across 1000 compromises), so 
> > you're not specifically targeted
> 
> That's the old "why use encryption if you have nothing to hide" 
> argument. I don't know who is going to target me, or what I may 
> need to use my encryption for in the future. My secrets are 
> valuable to me, regardless of an external monetary value someone 
> else may place on them, so I prefer to treat them all as important.

No it's not. It's "don't use encryption that's more expensive than your
secret is worth." Encryption has a cost that's real and measurable. Don't
spend more than you need. Use a method that's reasonable, practical, and 
appropriate for what's being protected.

> > #2 is the fax machine syndrome. Encryption's one of those things 
> > that becomes more useful when more people adopt it, because your 
> > specific encryption gets lost in the sea of everyone else's 
> > encryption. For that to be true, you have to keep the cost of 
> > entry low enough that people adopt it, which means you have to 
> > keep the key sizes small enough that they will work with people's 
> > software and hardware....
> 
> That's a ridiculous argument for small key sizes. First, >2048 is 
> not an unreasonably large key size. Second, saying your "specific 
> encryption gets lost in the sea" is beside the point. Use good 
> encryption: the number of other people using it is irrelevant.
> Do you think the NSA just randomly pulls encrypted messages out 
> of the Internet to practice on? How can it matter how many 
> other encrypted messages are out there?

It's not at all irrelevant. Processing power, even of NSA and co-agencies 
(Echelon), is finite. Increase the number of signals they have to filter, 
and you inevitably increase the number of targets they miss.

> > But that's always the case. Encryption will *never* protect you 
> > against someone with enough money. So it's not cost-feasible to 
> > crack your 4096-bit key today? Fine. I save your traffic, then 
> > wait 10 years, or 20 years, or 50 years (there's plenty of traffic 
> > which will still have financial value if decoded 50 years from now. 
> > Think about, say, an email containing a trade secret like the 
> > formula of Coke). Moore's Law will have made it affordable for 
> > me to crack it then....
> 
> But encryption will protect you, regardless of how much money 
> someone has. That's the beauty of it. The secrets you have should be 
> protected to a reasonable extent against current and futuristic 
> technology.

Make up your mind. Do you want unlimited protection (as you argue above), or 
do you want "protection to a reasonable extent", as you state here and as 
I'm saying is appropriate?

I suspect we just disagree on the definition of "reasonable extent" ;-)

> > You can never get absolute protection, at least w/ current methods. 
> > You can only get "good enough"  protection. And for most people and 
> > most data today, 1024 bits is still "good enough".
> 
> I am not sure I understand this argument. If all you want is 
> "good enough", why not go to a 56 bit key? Or one of the older 
> algorithms? After all, are they not "good enough" for most data? Even 
> if your data is not important today, what about tomorrow? Why wait for 
> the day when you need really good encryption?

I use 56-bit encryption every day of my life, simply because Unix doesn't 
offer me better options (well, Solaris 12/02 does, but no one's using that 
in production yet, and they aren't likely to switch password encryption when 
they do). Is it weak? Sure. Does it suck? Sure. Does it do the job? Yes.

> When it all comes down to it, 1024 is probably still secure, but 
> there is no harm (and great future benefit), in going to 2048 or 
> 4096 as your key size. Brute forcing is always the means of last 
> defense, as there are plenty of other ways for other people to 
> compromise your key, but it never hurts to make every link in 
> your chain as strong as possible.

*shrug* And I simply disagree. Encryption is needed on lots of devices and
places where 4096-bit keys simply are not practical. That's one reason
there's a lot of research in things like elliptic curves, which can be
computed in reasonable times on embedded equipment.

later,
chris
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale