Cryptography-Digest Digest #798, Volume #12 Fri, 29 Sep 00 14:13:00 EDT
Contents:
Timing Attacks ([EMAIL PROTECTED])
Re: Newbie question to practical brute-force analysis (Roger Gammans)
Re: Non-Repudiation mechanism ("Kevin Crosbie")
Re: CPU's aimed at cryptography (Mike Rosing)
Re: Which is better? CRC or Hash? ("Tomas Rosa")
Re: Newbie question to practical brute-force analysis (Jim Gillogly)
AES annoucement due Monday 2nd October (David Crick)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Timing Attacks
Date: Fri, 29 Sep 2000 16:55:25 GMT
Hi all,
I would like to point your attention to this article that i have co-
written with Prof Kit Dodson from UMIST in MAnchester, UK on Timing
Attacks:
http://www.ma.umist.ac.uk/kd/PREPRINTS/rsatim.ps
I would your thoughts and feedback on the content of this paper.
Thank you very much for your help.
Brice Canvel.
P.S. : Could people email any comments/suggestions they have to
[EMAIL PROTECTED], thank you.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: Re: Newbie question to practical brute-force analysis
Date: Fri, 29 Sep 2000 17:18:00 GMT
In article <[EMAIL PROTECTED]>, Jim Gillogly wrote:
> <snip>
> The second step is to look carefully at the ciphertext and
>see if you can determine anything from statistical properties such
>as character frequency, repeated strings, periodic behavior, and
>range. Look especially closely at the beginning of the file, in case
>it's one of the cryptosystems that leaves tracks so that it can
What sort of differences would one expect to see in the output
of different modern block & stream ciphers?
In the case of block ciphers, presumably repeated blocks give away
codebook mode and and block length (Detected via say auto-correlation),
but are there other simple tricks and idiosyncrasies in the output you
can look for?
TTFN
--
Roger
Think of the mess on the carpet. Sensible people do all their
demon-summoning in the garage, which you can just hose down afterwards.
-- [EMAIL PROTECTED]
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Re: Non-Repudiation mechanism
Date: 29 Sep 2000 17:22:00 GMT
More comments.....
"Lyalc" <[EMAIL PROTECTED]> wrote in message
news:Yw%A5.12937$[EMAIL PROTECTED]...
> comments inline
>
> Kevin Crosbie wrote in message <8r00gi$[EMAIL PROTECTED]>...
> >Layal,
> >
> >Comments below:
> >
> >
> >"Lyalc" <[EMAIL PROTECTED]> wrote in message
> >news:rpyA5.7514$[EMAIL PROTECTED]...
> >> Sigh...
> >>
> >> What happens when a valid user gets 2 or more valid certificates (as
per
> >the
> >> bogus cert attack described)?
> >
> >Well the user can only have one valid cert registered in my database,
they
> >can't apply for a second as long as there is one in existence in the
> >database. If they manage to get a second using an insider's help, it
> won't
> >match the PKCS#7 signer certificate, and I can say that foul play has
> >occured. I'm not sure of the legal aspects of this.
>
>
> A race condition - the first one to get a certificate is designated the
> 'real' identity, regardless of acual identity
This system is dependant on an initial authentication mechanism. We can
(I'm not sure if we do yet) restrict to one logon session per user. That
destroys the race condition... the only problem is if the user gets their
authentication mechanism stolen... not a race condition, rather a security
condition. The restriction of one logon session per user is really only
an issue if there is a possibility of the user getting their authentication
mechanism stolen... in which case, anyone can masquerade as the user, even
for signing purposes... which is still really pointing to the fact that if
you let your authentication mechanism get stolen, then you are allowing
people to pose as you.
>
>
> >> Smartcards need a 'secure' reader that incorporates a keypad or
biometric
> >> entry device, especially if you want to move beyond an expensive
> >duplication
> >> of a password mechanism towards something that has some amount of legal
> >> validity.
> >
> >What are the current legal guidelines regarding this form of security at
> >present (password/browser cert/Smartcard)?
>
>
> No one really knows, as it hasn't been well tested (or maybe never tested
at
> all yet) since most jurisdictions have gone a technology neutral,
"approved
> standards" route, the latter having not yet been ratified except in a few
> rare, extremely narrow situations.
>
Like that case with Napster, where in my opinion, Metallica were being
assholes, but nonetheless, Napster were infringing on copyright.
The Judge allowed Napster to continue as he didn't know anything about the
subject, and so couldn't see any reason to stop them.
> >From my perspective, you can only do so much. If a smartcard password
> were
> >duplicated or stolen, I don't think that is my liability, but the
liability
> >of the user... proving that is another question though.
>
>
> Can the user control this situation, or are you knowingly forcing them to
> accept "less than ideal", and thus perhaps being negligent at law
> See your lawyer for a real opinion.
> Or look at the liability report at
> http://www.noie.gov.au/projects/consult/NEAC/index.htm
Yes, it is up to the user. We give them the option of user/pass, Browser
cert, smartcard, and they choose what meets their needs.
>
> >My Company works through browsers on the web. It is a contract
processing
> >system. A smartcard must me installed into the browser as a PKCS#11
> >device. It is up to the user or their company to ensure that this is a
> >secure system, otherwise, I don't see why I should take liability. The
> >choice of the authentication mechanism is not something I have too much
> >control over, but if a company wishes to have Non-Repudiation
strengthened,
> >let's say for expensive transactions(the company will want this as much
as
> >us) they will be responsible for their smartcards.
>
> >>
> >> How does the RA know this will be a valid cert request?
> >> Simply by duplicating all the validation mechanism at another location.
> >
> >It doesn't. But the cert returned by the RA has to go into my system
and
> >saved to the database to be of any use, as it is a method for verifying
the
> >PKCS#7 signed data of a non-repudiable signature.
>
>
> See the race condition above.
>
> What happens when a valid user gets a new certificate?
> Do you archive the old certificate? if not, no 'old' signature can be
> verified, and is hence a waste of storage space- it has no other meaning.
> All the 'contracts' become nothing more than bits on a disk - do you have
> corporate laws that require accurate, verifiable archival of all company
> records?
>
I will be archiving the old certificate, as the signed data will be
timestamped, allowing me to say which 'old' or 'new' certificate is required
to check this cert. Having the old cert is a big requirement for
Non-Repudiation.
> >> More procedures, more systems/services holding duplicate info 9or with
> >> access to a master copy.
> >> The management hassles of the above aren't worth it unless you're a
> >> government dept which can bury losses for decades.
> >
> >The database need only be on one or two machines. The relevant fields
> >shall be encrypted using a HSM, and access to the HSM for
> >developers(insiders) is restricted to smartcard usage. For the system
to
> >use the HSM, on bootup, three or more smartcards must be present to load
> the
> >system, ensuring that more than one insider is necessary.
>
>
> The dabase protection you outline sems ok.
> How does the user validation get managed at inital certificate
registration?
>
out-of-band communication.
> >>
> >> Lyal
> >
> >Thanks for the feedback Lyal. I'm not sure if my counterarguments are
> >convincing, so tell me what you think.
> >
> >Cheers,
> >
> >Kevin
> >
> >>
> >> Kevin Crosbie wrote in message <8qu32m$[EMAIL PROTECTED]>...
> >> >Hi all,
> >> >
> >> >I have been searching for a solution for performing cross-platform
> >> >non-repudiation for web-sites.
> >> >I have not been in the security field for long enough to know if this
> >> >solution is good enough, or if it has major flaws, so I decided to put
> it
> >> >into the public domain for feedback. This solution is similar to
that
> >> >given by Baltimore's FormSecure signed applet system.
> >> >
> >> >The System works as follows:
> >> >
> >> >We have a Client Browser, a Web-Server, and a Certificatation
> >> >Authority/Registration Authority.
> >> >
> >> >First of all, to use the Service I provide, the user must authenticate
> by
> >> >either a username/password, Browser Cert or Smartcard.
> >> >
> >> >When the client goes to a certain page, they are requested to download
a
> >> >signed-persistent applet. The applet on first load will generate an
> RSA
> >> >KeyPair, and a Certificate request. The Private key is stored, and
the
> >> >Cert Request is posted to a servlet on the web-browser. The servlet
> >will
> >> >check the request, and send it to an RA, which will automatically send
> >this
> >> >on to the CA, who will sign the cert, return it to the RA, who will in
> >turn
> >> >return it to the servlet.(Is this structure in place anywhere, I think
> >> >Unicert does this automatic process.)
> >> >
> >> >Point: The cert doesn't tie to the user, as it was an automatic
process,
> >> >using an ARM, or worse, nothing, the only thing I have is that the
user
> >> >authenticated using their authentication mechanism, and that I can see
> >the
> >> >generated cert at a time that they were authenticated.
> >> >
> >> >On receipt of the CA signed cert, the servlet will save the
> >cert(encrypted)
> >> >to a database, and return it to the applet (anybody know how long it
> >takes
> >> >for the cert registration process to complete?) The applet will then
> >save
> >> >this to a disk(password protected in a PFX file in the JVM
> >> >System.getProperty(" user.home") directory)
> >> >
> >> >When a signature for non-repudiation takes place, the applet is called
> to
> >> >sign a piece of data, prompt the user for their password, and return a
> >> piece
> >> >of PKCS#7 data containing the signed data object, which is sent to the
> >> >servlet, timestamped and stored in the users account for arbitration
in
> >the
> >> >case of a dispute. Before the signature is stored, it is validated
> >> against
> >> >a CRL on the CA, and with the signing cert stored in the database, to
> >make
> >> >sure it is still the cert first applied for, otherwise it is rejected.
> >> >
> >> >That is the system. I can see one obvious point of attack:
> >> >
> >> >Someone inside my company could apply for a new certificate using the
> >same
> >> >automatic process, encrypt it, and store it, give the cert components
> >> >including the private exponent to the user. The user will authorize a
> >> >transaction which is supposed to be non-repudiable, and this validates
> >ok,
> >> >and the signed data get's stored.
> >> >The insider replaces the origional encrypted cert. A dispute takes
> >place
> >> >and we see, hey the signature certificate doesn't match that in the
> >PKCS#7
> >> >object. Non-Repudiation fails.
> >> >
> >> >Notes:
> >> >The user must authenticate with the authentication mechanism, thus,
> >unless
> >> >this is also replaced, and a bogus user created, we can show that the
> >user
> >> >had a part in this, or that their authentication mechanism was stolen
by
> >a
> >> >malicious party.
> >> >
> >> >When a signature doesn't match in the arbitration process, we can tell
> >> >straight off that the system was tampered with.
> >> >
> >> >Points:
> >> >1. Without smartcards being used exclusively, the is no way to say for
> >sure
> >> >that the person is who they say they are.
> >> >2. We can make this system as secure as we can from an insider attack
by
> >> >requiring smartcards to use database encryption/decryption functions
> >which
> >> >are done through a Hardware Security Module.
> >> >3. The way that we are using the certs, a trail is left in the case of
> >> >tampering, showing us that the user was wither negligent, or
fraudulent,
> >> >posing the question, would we be expected to take liability in the
case
> >of
> >> >negligence or fraudulence?
> >> >
> >> >That is basically all I can say about the system. Please review this
> >and
> >> >give me feedback. It is a solution, but I'm not sure if it is the
best
> >> >solution.
> >> >
> >> >Best Regards,
> >> >
> >> >Kevin
> >> >
> >> >
> >>
> >>
> >
> >
>
>
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: CPU's aimed at cryptography
Date: Fri, 29 Sep 2000 12:36:00 -0500
JCA wrote:
>
> If we are talking 1024-bit RSA moduli, 32 ms for the signature
> time is very unimpressive. Similar or better speeds are already
> achieved in software on a medium range PA-RISC box, and much
> faster performance on a 500 MHz IA64 box.
But check out the M180e:
Public Key Execution Unit
- RSA signature time of 32ms supporting 13 IKE handshakes per second.
- Elliptic Curve cryptography signature time of 11ms supporting 45.5 IKE
hand- shakes per second.
RSA isn't the target market.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Tomas Rosa" <[EMAIL PROTECTED]>
Subject: Re: Which is better? CRC or Hash?
Date: Fri, 29 Sep 2000 14:25:38 +0200
"Tiemo Ehlers" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I want to be able to notice any changes, no matter if done by evil forces
or
> just by coincidence.
There will always be some undetectable error patterns when using these
methods - all you can do is to try to minimize the probability that randomly
choosen error pattern is not detectable.
> And it should be infeasable to generate a file with a different content
but
> the same digest number.
If so, then forget CRC at all.
> I think real one way hash functions would do that job.
>
> But CRC is easier to computer. How likely is it to generate a file with a
> different content and the same CRC value as before?
> I don't have a clue. How can I find out?
It is question of simple algebraic operations on the ring F[x]. Let say you
have a codeword c(x) with the syndrome s(x). It holds, that s(x) = c(x) mod
g(x), where g(x) is the generating polynomial for the particular code. Now,
if you want to have c2(x) other than c(x), but with the same syndrome, than
simple put c2(x) = k(x)g(x) + c(x), where deg(k(x)) >-1.
> David Blackman wrote:
>
> > Tiemo Ehlers wrote:
> > >
> > > I want to find out if a data file (size: about half meg) has been
> > > changed.
> > > I can get a digest number with a hash function (RIPEMD or SHA) 160 bit
> > > wide or so.
> > > I can also use a CRC, 32, 64 or higher to get a remainder or some kind
> > > of digest number.
> > >
> > > Which way is the better one?
> > > I have doubts using CRC because it is based on the modulo operation.
> > >
> > > Tiemo
> >
> > Depends what kind of changes you're worried about. If you're worried
> > that an evil person will sneak in and change the file, then you'd better
> > use SHA-1 or Tiger or one of the other crypto quality hashes. (And store
> > the hash somewhere that evil people can't get at to change them.)
> >
> > If you're just hoping to detect accidental changes, just about any hash
> > or checksum of 32 bits or more is fairly good. But there's still nothing
> > wrong with using a good crypto hash function even for that.
> >
> > On only half a meg, just about any well known hash or checksum will run
> > in a small fraction of a second on most PCs, so speed probably won't be
> > a problem.
>
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Newbie question to practical brute-force analysis
Date: Fri, 29 Sep 2000 17:50:08 +0000
Roger Gammans wrote:
>
> In article <[EMAIL PROTECTED]>, Jim Gillogly wrote:
> > <snip>
> > The second step is to look carefully at the ciphertext and
> >see if you can determine anything from statistical properties such
> >as character frequency, repeated strings, periodic behavior, and
> >range. Look especially closely at the beginning of the file, in case
> >it's one of the cryptosystems that leaves tracks so that it can
>
> What sort of differences would one expect to see in the output
> of different modern block & stream ciphers?
Not much for the ciphertext itself. However, the cryptosystem may leave
tracks: PGP clones will have RFC 2440-style packets, for example, and
these are quite recognizable. Zip-encrypted archives have a
distinctive header. Kremlin has a recognizable header. Some of them
use ASN format which tells both the algorithm and the key length.
I assume many of the standard bogo-crypto mail handlers will have
handles that they can grab on the other end when they see their text.
When I say "not much" I'm leaving out things like the observation that
RC4 has been reported to have a very small but significant bias when
viewed on very long files.
Also, of course, the answer may be that this is <not> a modern block
or steam cipher, and if this is the case your statistical analysis
may give you big hints about what kind of cipher it is.
> In the case of block ciphers, presumably repeated blocks give away
> codebook mode and and block length (Detected via say auto-correlation),
> but are there other simple tricks and idiosyncrasies in the output you
> can look for?
>
> TTFN
HTH.
--
Jim Gillogly
Sterday, 8 Winterfilth S.R. 2000, 17:41
12.19.7.10.12, 8 Eb 15 Chen, Fifth Lord of Night
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: AES annoucement due Monday 2nd October
Date: Fri, 29 Sep 2000 19:03:46 +0100
http://csrc.nist.gov/encryption/aes/
====================================
AES ANNOUNCEMENT:
Monday, October 2, 2000
TIME:
11:00 a.m. Eastern Daylight Time
PLACE:
Lecture Room D, Administration Bldg. (Bldg. 101),
NIST, Gaithersburg, Md.
PARTICIPANTS:
Under Secretary of Commerce for Technology Dr.
Cheryl L. Shavers
NIST Director Ray Kammer
Acting Chief of NIST's Computer Security Division
Ed Roback
WEBCAST:
Anyone who wishes to view a real-time webcast of
the press conference may do so by accessing
http://real.nist.gov and then clicking on "LIVE
BROADCASTS." That site also contains links to
various streaming media players.
OTHER:
Following the announcement, NIST will be posting its
"Report on the Development of the Advanced
Encryption Standard (AES)" on this site.
Additionally, the number and name(s) of NIST's
selection for the AES will NOT be announced before
the official announcement.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (SEP-2000 KEY) 0x3226F499 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
