Cryptography-Digest Digest #937, Volume #13 Mon, 19 Mar 01 00:13:01 EST
Contents:
Re: DES in software and hardware ("Tor Rustad")
Re: ideas of D.Chaum about digital cash and whether tax offices are (Bart Bailey)
Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION (Mok-Kong Shen)
Re: Random and RSA (John Myre)
Re: Random and RSA ("JCA")
Re: Idea (John Savard)
Re: ideas of D.Chaum about digital cash and whether tax offices are ("Trevor L.
Jackson, III")
Re: IP ("Fred")
Re: Idea ("Henrick Hellström")
Re: Idea (John Joseph Trammell)
Re: Algebraic 1024-bit block cipher ("Henrick Hellström")
Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
(wtshaw)
Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
(wtshaw)
Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
(wtshaw)
Re: How to eliminate redondancy? (Nicol So)
Re: Idea (John Savard)
Is SHA-1 Broken? (Jim Steuert)
Re: Is SHA-1 Broken? (Paul Rubin)
----------------------------------------------------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: DES in software and hardware
Date: Mon, 19 Mar 2001 00:28:11 +0100
"Lovecraftesque" <[EMAIL PROTECTED]> wrote in message
>
> I understand that hardware DES implementations are three orders of
> magnitude faster than software ones (roughly speaking.) I wonder if
> anybody can provide pointers to more precise data?
DES in HW is fast, we have some really old stand-alone boxes with i286 CPU
and DES chip, which perfoms very well even to day. 3DES based MAC
calculation of a 32 byte messsage, takes about 40 ms (measured from host),
here 50% of the time is due to communication on a slow HDLC 64 kbps link.
Even so, modern PCI based crypto cards may very well not deliver the
promised speed, at least the ones I have tested didn't beat my old boxes the
way I hoped...
How is this compared to a SW implementation? IMO, the main reason for using
HW, is to protect key-material, and *not* to speed up the encryption! What
kind of HW do you want to compare? Of course the answer depends on this.
E.g. my home PC has an advanced 651 Mhz CPU, which is somewhat different
than a 16 Mhz CPU with slow RAM and no cache....
> Also, what is usually the performance difference between C
> implementations and hand-coded assembly language ones? I am aware that
> there are many factors involved, like the type of platform and how good
> each implementation is but, again, feedback on this would be welcome.
Correct it depends, and it is not possible to make general statements on
this. Modern optimizing C compilers are very good and doing micro-optimizing
on C code is generally not recommended. This is expert stuff, and not even
an expert may be able to beat a good C optimizer. Modern CPUs are very
complex, some has branch prediction, multiple execution units, pipe-line,
etc. Hmm... at times adding an instruction may even speed up the execution!
Remember once I was playing with optimizing memcpy(), used every trick I
knew (pre-warming the cache, cache alignment, loop unrolling etc.) and got
the memcpy() implementation to performe better than the native Microsoft
VC++ 6.0 memcpy() on a Pentium CPU, but when recompiling on a Pentium II
CPU, I was beaten again...
However, an expert assembler programmer may be able to make the DES code run
50-100% faster, on *one* particular CPU, but this optimization work probably
need to be done again when the code is run on a different CPU, e.g.
optimized assembler for Pentium may very well run slower than a C
implementation on Pentium III...
--
Tor <torust AT online DOT no>
------------------------------
From: Bart Bailey <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
Date: Sun, 18 Mar 2001 14:42:14 -0800
Thomas J. Boschloo wrote:
> <~~~>
>
> I also had an somewhat related (anti-echelon) thought about firearms
> (since you Americans seem so obsessed with that). What if there would be
> a technology that allowed every bullet to be traced by some homing
> signal. Just like GSM phones are now. Would we use it to stop
> drive-by-shootings and terrorist actions in shopping malls? Maybe it is
> a bit far of, but what I am thinking is that bullets are basically
> anonymous messages that can be used for illegal activity. Just something
> to think about. I am very worried about the ammount of tracing that goes
> on nowadays and how it will affect the future of my grand-grand
> children. But I do suck at economics, law and politics :-(
~~Just a quick in and out comment here:
The radiated signal "tracking" as applied to cell phones isn't feasible from a
ballistic point of view, however the esn registration "tracing" concept might be
applied to bullets in a similar manner as is the addition of tagants to commercial
explosives. I suspect a rather vigorous resistance will be met by any proposal to
add tagants to hobby reloader supplies and all the paper trail implications it
suggests. You present the "good vs bad" conundrum that relates to firearms,
encrypted communications, or any other human activity that has the potential for
adaptation to causes with which you disagree.
Back lurking~~
~~Bart~~
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION
Date: Mon, 19 Mar 2001 01:26:02 +0100
amateur wrote:
>
> Why my idea about crypting the bits before encryption was rejected?
> I don't understand why?
> If for every bit (0) I assign one category and the other one (1) and I
> choose randomly the values, it's than hard if not impossible to decrypt.
You are apparently referring to stuffs of your threads
'Idea' and 'Caesar principle'. In one of these threads
John Malley has explained that what you do is a homophonic
encryption. Using homophones has the disadvantage of
incurring higher bandwidth. Modern block ciphers like AES
offer sufficiently high security so that additional use of
homophones seems barely to be worthwhile. Anyway, I am not
aware of practical applications that employ homophones of
bits, though I mentioned that possibility in a more general
framework some time back (see the thread 'A general
substitution scheme with variable-length codes' of 10th
Oct 2000).
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Random and RSA
Date: Sun, 18 Mar 2001 17:42:06 -0700
"Joe H. Acker" wrote:
<snip>
> It's sometimes called 'Fallacy of the Undistributed Middle'.
<snip>
That's it, all right, but it doesn't sound like the term I
think I used to know. I thought it was Latin, or maybe
Greek. (You know, one of those formal terms from class,
like modus ponens, and syllogism, and so forth.)
Oh, well.
JM
(BTW - nice site reference)
------------------------------
From: "JCA" <[EMAIL PROTECTED]>
Subject: Re: Random and RSA
Date: Sun, 18 Mar 2001 08:14:56 -0800
It's just a reality check for the original poster.
In article <[EMAIL PROTECTED]>, "those who know me have no
need of my name" <[EMAIL PROTECTED]> wrote:
> <98toab$s8t$[EMAIL PROTECTED]> divulged:
>>3648619747307346288823659931102648912027984439975493780829346715987758
>>2636039597999594334596226827651997112107402848167549330863512457575218
>>8698619439169071545606986083121263673550943113237113839445816060239485
>>0876228509053691549723304802264024332397042389689297353137878157027748
>>3241354391156478887788970461
> is that one of the current challenges?
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Idea
Date: Mon, 19 Mar 2001 02:27:52 GMT
On Sat, 17 Mar 2001 16:09:35 -0400, br <[EMAIL PROTECTED]> wrote, in part:
>I'm going to explain clearly my idea.
I'm afraid you have not succeeded in doing so.
I think you are saying that you want to encrypt a message more
securely by using a trick involving the following principle:
- divide the symbols of the plaintext alphabet into two classes
- encipher the symbols in each class by a separate algorithm
That is useful, although there are pitfalls.
If you encipher each symbol to a symbol in its own part of the
alphabet, then a frequency count might distinguish the pattern of
symbols in the two groups (if the ciphers are otherwise very secure,
so that frequencies within each group are flat).
If you rearrange the symbols somehow, you need to add extra
information to the message to allow it to be reconstructed.
For example, you could take a message consisting of bytes of binary
data, split it into two groups consisting of the bytes starting with 0
and the bytes starting with 1. Putting the bytes in the first group
first - as 7-bit symbols - followed by the bytes in the second group,
encipher these bits in DES. But the first bit of each byte is also
needed, to indicate where these 7-bit symbols are to be put to
reconstruct the message.
My web site, in the first chapter of 'A Cryptographic Compendium',
talks about a number of elaborate fractionation schemes. Perhaps you
will see something there similar to your idea.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
Date: Mon, 19 Mar 2001 03:21:13 GMT
Bart Bailey wrote:
> Thomas J. Boschloo wrote:
>
> > <~~~>
> >
> > I also had an somewhat related (anti-echelon) thought about firearms
> > (since you Americans seem so obsessed with that). What if there would be
> > a technology that allowed every bullet to be traced by some homing
> > signal. Just like GSM phones are now. Would we use it to stop
> > drive-by-shootings and terrorist actions in shopping malls? Maybe it is
> > a bit far of, but what I am thinking is that bullets are basically
> > anonymous messages that can be used for illegal activity. Just something
> > to think about. I am very worried about the ammount of tracing that goes
> > on nowadays and how it will affect the future of my grand-grand
> > children. But I do suck at economics, law and politics :-(
>
> ~~Just a quick in and out comment here:
> The radiated signal "tracking" as applied to cell phones isn't feasible from a
> ballistic point of view, however the esn registration "tracing" concept might be
> applied to bullets in a similar manner as is the addition of tagants to commercial
> explosives. I suspect a rather vigorous resistance will be met by any proposal to
> add tagants to hobby reloader supplies and all the paper trail implications it
> suggests.
There's also a problem with stability in the face of reloader's constant attempts to
experiment. Taggants make the propellant behavior much harder to predict for a
handloader making 100 rounds as compared to a factory making millions or billions or
rounds.
Reloaders buy propellant, but the make bullets. So tagging bullets will quickly lead
to counterfeit tags.
> You present the "good vs bad" conundrum that relates to firearms,
> encrypted communications, or any other human activity that has the potential for
> adaptation to causes with which you disagree.
> Back lurking~~
>
> ~~Bart~~
------------------------------
Reply-To: "Fred" <[EMAIL PROTECTED]>
From: "Fred" <[EMAIL PROTECTED]>
Subject: Re: IP
Date: Sat, 17 Mar 2001 22:24:30 -0500
Hello,
> A static IP address greatly diminishes anonymity
Nah, becose the providers delete log afters months, and, a gouvernement (
dont remember witch ), is trying to saves logs for 5 or 7 years. Where is
the anonymity?
> the amount of time that an attacker has to compromise a system, since
> the system is always available at the same address.
If the hacker have access to the box one time, He will put a tracer on the
remote computer, and come back after.... it's not a propblem.
Salutations,
Fred
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Mon, 19 Mar 2001 04:31:53 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (John Joseph Trammell) wrote in
> <[EMAIL PROTECTED]>:
>
> >On Sun, 18 Mar 2001 12:59:56 -0400, amateur <[EMAIL PROTECTED]> wrote:
> >> If you are so confident, I will send you encrypted message with
> >> the same algo and decrypt it.
> >
> >If you are so confident, prove to me that you're qualified to
> >write a cryptosystem. :-)
> >
>
> I hate it when people think it is necessiary to prove one
> is qualified to do something. Just what the hell does that mean.
> If the guy is a live he is qualifed. Pices of paper usually
> don't mean shit. Qualifications are used to keep the community
> closed. Of couse the pompous assholes will find fault with many
> of so called ametur stuff and use that as an excuse to never really
> check what many ametures are doing.
> Taking teaching as an example. I am a retired engineer worked
> on programming inertial guidance systems on missles and aircraft.
> I used calculus every day. I tutored my kids in it and they passed
> the AP tests and got college credit no sweat California.
> Here in Texas they have a shortage of "qualifed math teachers".
> I spent a month and some bucks trying to get hired since they
> say they need math teachers. First roadblock every time you turn
> around the system wants more money. They wanted my college transcripts
> I give them to them. They asked after I called them a few weeks
> later that I did not have algebra or trig. I started college on a
> math scholarshop and took calculus off the bat. That seened to
> confuse them. Then they sent a list of classes I needed to take
> and a schedule of fees in the thousands of dollars I would have to
> pay. Thats just to get started.
I agree to a large extent: It seems irrelevant or even ignorant to ask
someone what he has done in the past, if the primary question is how good
the immediate results of that person's last action is. But in many cases the
primary question is a different one - how well will he perform in the
future? In such cases there seems to be no other way than to look at past
achievements, and you can only evaluate these achievements if someone you
can trust has recorded them.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: Idea
Date: Mon, 19 Mar 2001 03:58:08 GMT
On 18 Mar 2001 19:50:25 GMT, SCOTT19U.ZIP_GUY wrote:
>[EMAIL PROTECTED] (John Joseph Trammell):
>>If you are so confident, prove to me that you're qualified to
>>write a cryptosystem. :-)
[rant snipped]
What an emotional response. I must have touched a nerve.
Let me know when you all decide to get around to working
on cryptography instead of (a) frothing at the mouth or
(b) taking wild stabs at cryptosystems.
Oh, and lighten up. There's a smiley in the message for
a reason. And learn how to use a spellchecker.
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Algebraic 1024-bit block cipher
Date: Mon, 19 Mar 2001 05:19:29 +0100
"Gregory G Rose" <[EMAIL PROTECTED]> skrev i meddelandet
news:99383c$[EMAIL PROTECTED]...
> In article <Irns6.50038$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >Right off the bat. What the heck does "group with order 65536" mean. Do
> >you mean a multiplicative sub-group of GF(65537) where your base is
> >primitive?
>
> There is a perfectly good group of order 2^16,
> namely GF(2^16), whose elements are polynomials
> with binary coefficients of degree less than 16,
> where the polynomial "0" is the additive identity,
> where the polynomial "1" is the multiplicative
> identity, where addition is mod-2 addition of the
> corresponding coefficients (XOR when they are implemented as bit
> vectors), and multiplication is polynomial
> multiplication reduced modulo an irreducible
> degree-16 binary polynomial.
>
> However he does say that he doesn't use XOR, so I
> agree that both postings (his and yours) may be
> ill-considered. I'll let other people comment on
> mine. :-)
That's nice :-)
I would use the expression "Z(2)[x](p(x)) where the degree of p(x) is 16" to
denote the kind of field you describe. "Z(2)" to denote the field of the
coefficients. "[x]" to indicate a polynomial field. "(p(x))" to denote the
polynomial modulus. There are other equally good notations, but GF(2^16)
won't do since all it appears to say is "The algebraic structure formed by
taking a finite field modulo it's element 2^16", and that's not even
consistent with what you described. Furthermore, a group is an algebraic
structure with one binary operation. You are talking about both addition and
multiplication, so I guess you mean "field" and not "group".
Just an opinion, mostly because I generally don't like to read cryptographic
papers where the expression "GF" pops up without any kind of precise
definition of the finite field in question. I am presumably just as bad in
other respects...
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
Date: Sun, 18 Mar 2001 22:11:14 -0600
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
> Murray is describing the strength of the cipher in the context of it
> being a component of a real crypto system, and you are considering the
> strength of a cipher in isolation.
>
> A cipher in isolation should have some objective [theoretical] strength
> value... or rather a strength function in terms of time and memory. But
> ciphers aren't used in theory, they are used in practice (remember my
> sig).
>
> A when cipher is part of a real system, we *can* try to measure the
> real, practical (non- theoretical or subjective) cost of breaking the
> system, and we *can* try to measure the real, practical (non-
> theoretical or subjective) value of breaking the system. If the cost to
> break the cryptosystem is less than the real value of the real
> information which would be gained, then the cryptosystem is broken.
>
> Cryptography is one of those fields where the difference between theory
> and practice is not a thin grey line, but a vast chasm. Good strong
> bridges with scrupulous inspections are a must.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
I speak from the real world of practive. If I didn't, I would be is sad
shape, as experimentation and experience can help you tweak ideas in the
real world. I guess I am reminded of Patton, as GCS did it, I have
crossed the river and wonder why so many are still saying that they
can't. Come on it, the water is fine.
--
Most [cryptographic] algorithms are based on assumptions which
could turn out to be false. -- Ron Rivest
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
Date: Sun, 18 Mar 2001 21:50:45 -0600
In article <[EMAIL PROTECTED]>, "John A. Malley"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > In article <[EMAIL PROTECTED]>, "John A. Malley"
> > <[EMAIL PROTECTED]> wrote:
....
>
> > > uncertainty of the key and D is the plaintext's redundancy expressed in
> > > bits/symbol (or D in this equation is the difference between the log of
> > > the number of characters and the average amount of information carried
> > > per character as actually used.)
>
> > This uncertainty value seems to be an out. What range do you suggest
it can be?
> ...
>
> With less than U characters of ciphertext the cryptanalyst cannot be
> 100% sure of the exact key used to encrypt the ciphertext - even if
> every key is checked! That's an amazing fact we hardly ever mention
> when talking about brute-force attacks on ciphers. Brute force is not
> guaranteed to reveal *the* secret key when the amount of ciphertext is
> less than the unicity distance of ciphertext.
>
> We can increase the unicity distance by holding the uncertainty of the
> key constant, by fixing the bit size of the key, and reducing the
> redundancy in the plaintext with compression prior to encryption. The
> more redundancy we squeeze out, the larger we make the unicity distance.
>
> Or we can increase the unicity distance by holding the redundancy of the
> plaintext constant (no compression) and increasing the uncertainty of
> the key (by increasing the key bit length.)
> ....
>
> What happens to the work characteristic W(n) of a given cipher type as
> the unicity distance U increases and/or the key size increases?
>
> I don't exactly know :-(
>
> But, here's a swag at a model -
>
> The work characteristic is (probably) directly proportional to the key
> size in bits, double the key size, double the work. So I assume W(n) is
> proportional to H(K).
>
> The work characteristic is (probably) directly proportional to the
> unicity distance U.
> ...
>
> John A. Malley
> [EMAIL PROTECTED]
I have presented a cipher where the amount of key used is indeed
uncertain. I see that type of uncertainty as relative this discussion,
and should greatly increase what is referenced to as the unicity distance.
--
Most [cryptographic] algorithms are based on assumptions which
could turn out to be false. -- Ron Rivest
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
Date: Sun, 18 Mar 2001 22:01:19 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> I don't think any reasonable normal person ever neglects
> security. But it is important to be conscious that any
> claimed security could be inaccurate and that perfect
> security is never attainable. If you step into an airplane,
> you should realize that there IS a non-zero risk and
> that you have trusted that the engineers and the mechanists
> have done a good job, that the pilots will do right, etc. etc.
> If you want a formal proof that the risk is zero, on the
> other hand, then you have to remain on the ground,
> unfortunately. This is reality of life.
>
> M. K. Shen
Putting security in your own hands can amend the process. When planes
refused to floy Boston or Providence way dufing the so called blizzard a
few days ago, we switched for a plane from Atlanta to Baltimore, and drove
the rest of the way. Because of the weather, we met almost no traffic in
New Jersey, even New York City, drove right through, averaged good time.
In fear of insecurity, the world made our rather much better. This is all
a metaphor for the misplaced trust that the experts are always right. So
many simply could not make it...too bad, their loss. Be creative, folks.
--
Most [cryptographic] algorithms are based on assumptions which
could turn out to be false. -- Ron Rivest
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Sun, 18 Mar 2001 23:23:33 -0500
Reply-To: see.signature
[In the article Trevor L Jackson III was reponding to, I discussed the
definition of redundancy and why masking plaintext with PRNG does not
affect redundancy.]
"Trevor L. Jackson, III" wrote:
>
> I'll not waste a lot of time on rebutting the individual statements, but merely
> observe that the final statement is false. The phrase "theoretically best
> encoder of the masked plaintext stream" can only exist in the context of the
> weighted message space.
I don't know what you meant by a "weighted message space".
> Now, for extra credit, what do you think the OP, br, meant when he asked the
> original question? Did he mean apparent (a metric applicable to a single
> message) or "latent" (a metric applicable only to a sample of a weighted
> message space)?
I *think* the original poster was asking about reducing redundancy as
the concept is used in information theory. It was you, based on the
statement you made, that I thought had "apparent" redundancy in mind. I
didn't use the word "latent" and don't know how you use it. The concept
of redundancy is meaningful only when discussed in the context of a
probability distribution.
> Obviously I thought he meant the former, and that is the context in which my
> reply makes sense. Note also that PRNG masking is a form of lossless
> compression (with zero efficiency), so the distinction you constructed is not
> really applicable.
If you want to model PRNG masking as a form of degenerate lossless
compression, that's fine. But that doesn't mean it reduces the
redundancy in the source messages. Usually the term compression is used
when the source is compressible, i.e. not of maximal entropy, AND the
compressor achieves a non-zero amount of compression on average. If you
want to include degenerate schemes as compression, then I would reword
what I said to "Non-degenerate lossless compression... reduces
redundancy because it makes the information representation more
'compact'". The amount of redundancy reduction depends on the
compression ratio. The greater the compression ratio, the more the
redundancy reduction. The closer to the degenerate case, the closer to
no redundancy reduction.
If redundancy as used in information theory was what you had in mind,
your statement was false. Although masking plaintext using a PRNG
usually makes the distribution of symbols more uniformly distributed,
*when you model successive masked symbols as independent and identically
distributed RVs*, that's NOT a reduction in redundancy. It only appears
so because the wrong (non-optimal) statistical model is used. With the
right predictor, an obvious example of which has the PRNG and its
parameters built in, a compressor can still be constructed to shorten
the masked plaintext to the same degree as the unmasked version, showing
that masking does not remove redundancy. It is critical that an optimal
statistical model is used.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Idea
Date: Mon, 19 Mar 2001 04:19:41 GMT
On 18 Mar 2001 19:50:25 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
>Of couse the pompous assholes will find fault with many
>of so called ametur stuff and use that as an excuse to never really
>check what many ametures are doing.
Given the number of hours in the day, and the fact that as far as most
amateur stuff is concerned, the time of the 'pompous' ones is better
spent for them working on their own stuff than looking at that, they
need _some_ excuse.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Is SHA-1 Broken?
Date: Sun, 18 Mar 2001 23:42:29 -0500
Reply-To: Jim, Steuert
Is SHA-1 Broken? In a recent thesis by
Richard Drews Dean, he
supplies initial values for SHA-1's
A,B,C,D,and E for which the
input block "abc" (in ascii, padded and
Merkle-Damgard strenghtened),
is a fixed point. He used the "Ever" BDD
(Binary Decision Diagram)
language for describing this. If this attack
yields some practical
results, then what are the implications
toward the design of future
hash functions? What can be done to resist
this kind of attack?
Are their types of constructs which are
resistant to this type of
modeling. In the sense that addition provides
more diffusion than xor
(because of carry bits), do certain
operations provide
more boolean complexity which would thwart
such automated modeling?
Does anyone in this group have experience
with cryptanalysis using
this type of tool?
Reference: "Formal Aspects of Mobile Code
Security", by Richard Drews Dean
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Is SHA-1 Broken?
Date: 18 Mar 2001 20:59:16 -0800
Jim Steuert <[EMAIL PROTECTED]> writes:
> Is SHA-1 Broken? In a recent thesis by Richard Drews Dean, he
> supplies initial values for SHA-1's A,B,C,D,and E for which the
> input block "abc" (in ascii, padded and Merkle-Damgard
> strenghtened), is a fixed point.
What precisely does the result say?
Is the thesis available online? How about offline?
Thanks.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
