|
|
|
|
|
by problemdomain
5006 days ago
|
|
A couple years ago I ran tests on an embedded Broadcom platform (7413, clocked at 400MHz IIRC) because I wasn't sure what was reasonable for SSL certificates when a box like that was involved. I ended up using 2048 for both the client and server certificates. 4096 on the client would have taken several seconds to negotiate, and 4096 on the server was too expensive for the number of clients I wanted to pack onto a single server. (Also, I didn't have proper control of the entire client software stack, and the behavior of part of it with regard to session management and keepalive was extremely non-optimal.) Based on that experience, I don't think I'd really want to use a 16384-bit key on a low-resource system anytime soon. Right now, 2048 ought to be plenty for any information that doesn't have to be kept secret over a very long time horizon (decades, at least), and anything over 4096 is getting pretty paranoid. 16384 seems obscene. |
|