Re: perfomance vs. key size
From: George Ou (2038george_ou9127_at_2342netzero.com2897)
Date: 11/15/03
- Next message: Roger Schlafly: "Re: Qauntum Computers and brute forcing encryption"
- Previous message: Anne & Lynn Wheeler: "Re: perfomance vs. key size"
- In reply to: Henrick Hellström: "Re: perfomance vs. key size"
- Next in thread: Henrick Hellström: "Re: perfomance vs. key size"
- Reply: Henrick Hellström: "Re: perfomance vs. key size"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 15 Nov 2003 02:10:48 GMT
"Henrick Hellström" <henrick.hellstrm@telia.com> wrote in message
news:8bftb.37865$dP1.135486@newsc.telia.net...
> George Ou wrote:
>
> > True, but I really really hate applications in high level languages.
Take
> > Java for example, a typical program that would use 5 MBs of system
memory
> > when coded in C would use 40 MBs of system memory when coded in Java.
I've
> > had to deploy some of these stupid browser based applications such as
Oracle
> > 11i that takes 20-50 seconds to load (longer than OS boot). It's
already
> > bad enough as it is, God help us if everything is written in Java.
> >
> > I'll take MS CryptoAPI or OpenSSL over anything written in Java.
>
> That is why I am doing most of my coding in Object Pascal, which
> compiles into executable code. <g>
No problem there. I have nothing against anything that compiles to binaries
which run in under 10 MBs of system RAM. I don't know if that is the case
with Opject Pascal. I just know that there are a lot of people out there
clamoring for more things to be written in Java and I just cringe at the
thought. To me anything written in VB, Java, VB.net should only be used by
Corporate application developers where the user base is less than 500 and it
isn't worth the extra development effort to do it right in a hardcore
language like C. OSes, developer tools, commodity applications with many
users, anything that is used by the masses should be efficiently coded. In
that sense, I view anything written in a high level language as a toy or a
model.
> > This may be true on a slow 500 MHz Sun Sparc box (they still sell these
MHz
> > class machines today and try to sell you SSL accelerators). I doubt
this
> > would be a problem on a modern dual or even single P4/XEON 3+ GHz
machine
> > which only cost $1000 - $5000.
>
> Let's say you are using run time CA chaining, the ECDSA-ECDHE cipher
> suites for perfect forward secrecy and client certificates for client
> authentication. In such case the server will perform at least five
> public/private key operations per handshake:
>
> 1) Generate ephemeral public key
> 2) Sign ephemeral public key
> 3) Calculate shared secret
> 4) Verify client certificate signature
> 5) Verify client certificate verify message
>
> +100 connections per second during a couple of seconds might be enough
> to cripple the performance even of a server running on a 2*3+ GHz
> machine, provided that it is using an ECDSA-ECDHE cipher suite and a
> patent free EC implementation.
The reality is, I don't know too many sites that actually handle 100 new SSL
setups per second. That's over 8 million users a day. Maybe amazon.com's
e-com site in it's peak may get close to that level of utilization. But for
a site of that scale or anything close, they really should be using HW
cryptographic modules for FIPS 140-2 L3+ security and speed from an ASIC
optimized for SSL setup.
Oh and don't forget, any major site is going to be using a bank of servers
in load ballancing & failover mode. The traffic would be deligated to 100
front-end servers. I don't think anyone in their right mind would attempt
to shove 100 new sessions per second on to a single server with or without a
HW SSL module.
> I agree with your line of reasoning: In the long run hardware
> improvements matter more than the difference between comparable
> algorithms. However, you wrote that "ECC is much more efficient". This
> is not completely accurate since both RSA-1024 and DSA-1024 with
> Karatsuba multiplication and windowed exponentiation are actually faster
> on 32 bit CPUs compared to prime curve ECDH-192, provided that the
> patent free IEEE P1363 EC algorithms are used.
Perhaps I have too quickly bought in to Certicom's marketing. You know a
lot more about it than me, so I'll take you at your word unless I find out
otherwise.
George
- Next message: Roger Schlafly: "Re: Qauntum Computers and brute forcing encryption"
- Previous message: Anne & Lynn Wheeler: "Re: perfomance vs. key size"
- In reply to: Henrick Hellström: "Re: perfomance vs. key size"
- Next in thread: Henrick Hellström: "Re: perfomance vs. key size"
- Reply: Henrick Hellström: "Re: perfomance vs. key size"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
