Cryptography-Digest Digest #796, Volume #12 Fri, 29 Sep 00 09:13:00 EDT
Contents:
Re: Chaos theory (Jim Gillogly)
Re: Which is better? CRC or Hash? (Tiemo Ehlers)
Re: newbie question (Aaron Cannon)
CPU's aimed at cryptography ("kihdip")
Re: Chaos theory (Jim Gillogly)
Re: Deadline for AES... (Volker Hetzer)
Re: On-line Turing test? (Guy Macon)
Newbie question to practical brute-force analysis (Andre van Straaten)
Re: Non-Repudiation mechanism ("Lyalc")
Re: Newbie question to practical brute-force analysis (Jim Gillogly)
Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Chaos theory
Date: Fri, 29 Sep 2000 10:38:00 +0000
Tim Tyler wrote:
>
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Jim Gillogly <[EMAIL PROTECTED]> wrote:
>
> :> : In mathematics, however, chaos lies on the boundary between
> :> : order and disorder, and is a study of systems that have behavior
> :> : that's largely predictable statistically...
> :>
> :> Not necessarily correct - chaotic systems can be highly disordered.
>
> : Gillogly was closer to the mark.
>
> Except for the fact that he stated that "chaos lies on the boundary
> between order and disorder" - which isn't right at all - while my
> statement was correct.
While you may have some other view of chaos, mine is certainly shared
by many researchers. A quick web search on the phrase "between order
and disorder" turned up a bunch of hits, including:
http://www.ems.psu.edu/info/explore/Chaos.html
Chaotic systems - they seem to be messy and random, unpredictable;
yet close examination shows patterns and predictability. They inhabit
the zone between order and disorder.
http://www.millennial.org/~jwills/GIG/C/Chaos_theory.html
Chaos theory, and the ways that natural processes move between order
and disorder, brings us closer to understanding the shapes of clouds
the patterns and lack of patterns of running water and...
There's a book entitled "Quantum Chaos: Between Order and Disorder"
editd by Casati and Chirikiv.
I'm not trotting these out as definitive definitions of chaos or as
the final word -- as Doug Gwyn points out, there <is> no universally
accepted definition of chaos. I present them simply to point out
that my view of chaos is well within the envelope of what chaos
researchers are working on. The Wolfram definition I gave elsewhere
in this thread matches closely how I think about chaos.
In particular, the lack of complete randomness in dynamic systems
normally called "chaotic" enabled me to break two cryptosystems that
were claimed to be based on chaos, and the effectiveness of chaos
in cryptosystems is what this thread was about -- not about who
doesn't understand what chaos is or isn't.
--
Jim Gillogly
Sterday, 8 Winterfilth S.R. 2000, 10:06
12.19.7.10.12, 8 Eb 15 Chen, Fifth Lord of Night
------------------------------
From: Tiemo Ehlers <[EMAIL PROTECTED]>
Subject: Re: Which is better? CRC or Hash?
Date: Fri, 29 Sep 2000 12:45:48 +0200
I want to be able to notice any changes, no matter if done by evil forces or
just by coincidence.
And it should be infeasable to generate a file with a different content but
the same digest number.
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?
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: Aaron Cannon <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: 29 Sep 2000 10:08:17 GMT
Aaron Cannon <[EMAIL PROTECTED]> wrote:
: Thank you all for your helpful responses! I very much appreciate it. I
: think I'll just try to find a good secure prebuilt c library and use that.
: any recommendations on what single key algorithms are best and easiest to
: use? I was considering IDEA but I haven't heard anything on it for a
: while, and so I don't know if any weaknesses have been found in it.
: Thanks again for the help!
I did a little more research since posting that message and realized that
IDEA won't work because of the patent issue. So, I think I'd like to use
3DES. Does anyone know where I can obtain a public domain or freely
usable c library for 3des? Once again, thanks for any and all help!
--
"Man is superior to government and should remain master over it, not the
other way around."
Ezra Taft Benson (Teachings of Ezra Taft Benson, page 680)
ICQ #: 22773363
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: CPU's aimed at cryptography
Date: Fri, 29 Sep 2000 12:54:15 +0200
CPU especially designed for cryptography are available.
This is probably old news, but here are the links:
Motorola's CPU, MPC180 at:
http://mot-sps.com/news_center/press_releases/PR000926A.html
Analog Device's CPU, ADSP-2141 at:
http://products.analog.com/products/info.asp?product=ADSP-2141L
Kim
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Chaos theory
Date: Fri, 29 Sep 2000 11:03:20 +0000
Tim Tyler wrote:
> The Wolfram page you cite doesn't say the periods have to be short.
> They don't.
And they don't need to be short in order to offer an entry. In
particular, in the cryptosystem posted to sci.crypt I found the
plaintext by trying various starting states until I found some
that included orbits close to but not exactly the same as pieces
that had been used to encrypt the plaintext. I imagine the actual
period was quite long, but the set of orbits was dense enough to
allow wrong guesses to yield islands of correct plaintext. This
is not possible in strong modern cryptosystems.
When you ask "Does anyone know of any definitions by which (say)
modern block cyphers do *not* qualify as chaotic systems?" you
seem to be using an interpretation of chaos that's broad enough
to offer no particular insight into cryptography and cryptanalysis.
If I'm mistaken, then illuminate us: what intellectual leverage
on the crypto problem do you gain by viewing modern block ciphers
as chaotic systems?
--
Jim Gillogly
Sterday, 8 Winterfilth S.R. 2000, 10:53
12.19.7.10.12, 8 Eb 15 Chen, Fifth Lord of Night
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Deadline for AES...
Date: Fri, 29 Sep 2000 13:43:21 +0200
Mok-Kong Shen wrote:
> I am interested to know how did you arrive at a 'definite'
> latest date of release? Do you have some insider info?
I never said that *I* had arrived at a definite date.
But it seemed that the NISSC organisers did and I wanted to bring
this to notice in order to collect a few opinions.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: On-line Turing test?
Date: 29 Sep 2000 11:46:41 GMT
John Myre wrote:
>
>
>
>I'm wondering about a certain frequent poster here.
>
>Could it actually be a computer program? Since Eliza
>et al., it has been clear that by limiting the subject
>matter, we can do pretty well. And sci.crypt seems
>well suited: highly technical content, with a low
>expectation of competence.
>
>The posts in question are frequent, wordy, syntactically
>correct (for the most part), and rarely seem to mean
>much of anything. Responses often seem to be reacting
>to the words, rather than the point, and veer off into
>non-sequiturs without warning.
>
>Are we guinea pigs in an experiment?
>
>JM
http://www.compapp.dcu.ie/~humphrys/eliza.html
http://www.dotcomma.org/projects/aibots/
http://cogsci.ucsd.edu/~asaygin/tt/ttest.html
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Newbie question to practical brute-force analysis
Date: Fri, 29 Sep 2000 12:00:15 GMT
Hi!
Having a ciphertext only to decrypt, I would start with a brute-force
attack selecting an algorithm.
Feeding into the brute-force program different keys with different length,
I receive with every different key a possible plaintext.
As I have billions of attempts with different keys, how do I check if I
got something that could be a reasonable plaintext?
I'm sure there are different approaches for different situations, but what
are the MOST COMMON METHODS?
E.g., if I'm looking for a plaintext to be all ASCII, but if a program has
inserted some non-ASCII characters, I would disregard the whole file.
I could look for special patterns, but then as with every search, the more
specified my search pattern is, the more possible files I disregard.
Is a brute-force approach only feasible in practice if I'm looking for
something special in the given ciphertext?
(If I had a file which has been compressed and encrypted with different
algorithms one after another, it boils down finally to the same
question: how do I recognize a decrypted plaintext as something
reasonable.)
Thanks in advance.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Non-Repudiation mechanism
Date: Fri, 29 Sep 2000 23:02:36 +1000
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
>> 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.
>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
>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?
>> 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?
>>
>> 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: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Newbie question to practical brute-force analysis
Date: Fri, 29 Sep 2000 12:17:38 +0000
Andre van Straaten wrote:
> Having a ciphertext only to decrypt, I would start with a brute-force
> attack selecting an algorithm.
Wrong idea. There are too many algorithms, and if the system is a
good one then brute force won't help anyway. The first step if you
have ciphertext only is to try to find more about the origin of the
cipher. 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
determine whether it's looking at a valid message.
> Is a brute-force approach only feasible in practice if I'm looking for
> something special in the given ciphertext?
There are all kinds of different cryptanalysis attacks, and
they may or may not need to know anything about the plaintext.
> (If I had a file which has been compressed and encrypted with different
> algorithms one after another, it boils down finally to the same
> question: how do I recognize a decrypted plaintext as something
> reasonable.)
Better start smaller -- break some newspaper cryptograms, then get
Military Cryptanalytics and go through it. By then you should be
ready to read some of the modern papers on cryptanalysis. Most
people don't seem to go this far -- a lot more people design ciphers
than learn how to break them. This is rather like building a high-rise
on aesthetic principles without any input from structural engineers.
--
Jim Gillogly
Sterday, 8 Winterfilth S.R. 2000, 12:09
12.19.7.10.12, 8 Eb 15 Chen, Fifth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 29 Sep 2000 12:46:47 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in
<[EMAIL PROTECTED]>:
>Joseph Ashwood wrote:
>> I thought we both agreed that they would hire someone to spread as much
>> erroneous information as possible, impede the spread of knowledge, and
>> propogate the spread of their own wishes.
>
>The NSA exists to assert the security of the US, not the security of
>the rest of the world.
>
>But on the other hand it seems that they have actually helped IBM
>with DES, and until today nobody found any intentional weakness in
>DES, did anyone ?
>
Actually if you read the puzzle palace many great experts at
the time DES came out where in shock at its small key size. This
was a weakness designed in from the begining.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 29 Sep 2000 12:54:16 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in
<[EMAIL PROTECTED]>:
>Tom St Denis wrote:
>> Twofish is by far the best AES cipher.
>
>Maybe Twofish is the best, but not 'by far'. Its hardware performance
>is not that bright compared to Serpent and Rijndael, and it is not a
>truely simple cipher. Its (known) security per clocks performance in
>software is however unreached.
>
>In fact, maybe the ideal cipher would be adding some more rounds to
>Rijndael, the fastest in hardware, which is as fast as Twofish in
>software, but has, as far as we know, the by far lowest security
>of the three.
>
>Or maybe Serpent is best. It is based on very simple principles, has
>very much rounds, and is very cheap in hardware. The many rounds make
>it very slow in software, compared to the other three. I think Serpent
>is the most trustable of the AES finalists.
>
It is very possible Serpent is the best of the lot. Which is why
twofish will be chosen.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
** 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
******************************
