1995-10-19 - STT - useable in real life ?

Header Data

From: lyalc@ozemail.com.au (lyal collins)
To: cypherpunks@toad.com
Message Hash: 40296f515b2724e7c89569b46ce93a6c6939022535906992815e12fb25dfa113
Message ID: <199510191347.XAA17540@oznet02.ozemail.com.au>
Reply To: N/A
UTC Datetime: 1995-10-19 13:48:16 UTC
Raw Date: Thu, 19 Oct 95 06:48:16 PDT

Raw message

From: lyalc@ozemail.com.au (lyal collins)
Date: Thu, 19 Oct 95 06:48:16 PDT
To: cypherpunks@toad.com
Subject: STT - useable in real life ?
Message-ID: <199510191347.XAA17540@oznet02.ozemail.com.au>
MIME-Version: 1.0
Content-Type: text/plain


From reading the STT specs, a 'credential' is made up of typically 4
certificates - root, country CA, issuer Ca, and cardholder/merchant.
Two certificates are based upon a 1024 bit public keys, 1 (root) is 2048
while the cardholder PK is 512/768 bit.
I believe a decrypt operation is required to verify each certificate.
I have seen test result from a local crypto company which indicate a 1024
bit decrypt operation will take between 2.5-30 seconds (Pentium 90 - 386/33
- I am trying to relate this to userland, not the well equipped cybernaut).
PK encrypt is somewhat faster. 
On this basis, a credential verify will take 10+ seconds up to several
minutes, on this range of equipment.
This seems to take a significant amount of time in verifying certificates.
This situation will only get worse as renewal certificates are appended to
existing certificates.
Can someone comment, or steer me in the right direction if I have
misunderstood certificate verification ?
Working for a bank who may have to use this one day, customer impact is a
big deal - we can afford specialised  hardware, but not all our customers can.
thanks for any clarification,
 lyal
All mistakes in this message belong to me - you should not use them!






Thread