- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 20 Aug 2014 09:59:59 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 20 August 2014 00:29, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > I don't think the algorithm matters, as long as it's not buggy, the > bruteforcing will be done against the keys used. Let's go with this and run with it a little. Assume that you are using AES-GCM or something like it. That's 2^64 decryptions to get a 50/50 chance of success. The constant factor is the speed of the algorithm and it's key schedule. If you can do 10Gb/s on a single machine with Ilari's estimated ~1.7 cGHz and 14cGHz per core, that means something in the order of 900 machine years to brute force a single key. Based on some rough guesses on AWS (ECU to cGHz conversion) and current prices, that's going to set you back about USD170K. It's highly parallel, so don't expect to wait particularly long. Big caveat on the numbers, I've fudged a fair bit (on the pessimistic side). On the other hand, if you reduced the key size to 32-bit and increased the enciphering rate by a linear factor (4), that reduces the number of calculations significantly. That works out a cost for a brute force of USD0.0000000001 USD170K might be OK, depending on what you concern yourself with. Though it makes me think that a move to 256-bit ciphers might need to come sooner than I expected. On the other hand, any significant reduction in key size basically seems to amount to nothing short of an ineffectual cipher. Even a 64-bit cipher that increased throughput by a factor of 16 would be a trivial cost to brute force.
Received on Wednesday, 20 August 2014 17:00:30 UTC