Cryptography-Digest Digest #909, Volume #12 Fri, 13 Oct 00 07:13:01 EDT
Contents:
Re: CRC vs. HASH functions (Bryan Olson)
A5/1 ([EMAIL PROTECTED])
Re: Rijndael implementations (Rob Warnock)
Re: Why trust root CAs ? (Vernon Schryver)
Re: Why trust root CAs ? (Vernon Schryver)
Re: BlowFry... (Runu Knips)
Re: Idea for Twofish and Serpent Teams (Runu Knips)
Re: Why trust root CAs ? (Rob Warnock)
Re: CRC vs. HASH functions (Bryan Olson)
Re: SHA-256 implementation in pure C (free) (Dido Sevilla)
Re: FTL Computation (ca314159)
Challenge... ([EMAIL PROTECTED])
Re: More on the SDMI challenge (Dido Sevilla)
Re: Challenge... (Richard Heathfield)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Date: Fri, 13 Oct 2000 09:00:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> >Mack wrote:
> >
> >> CRC's are generally best for:
> >>
> >> 1) compressing entropy free from outside influence.
> >
> >That one is debatable. Noise (the part we want in this
> >application) that appeared largely in multiples of the
> >CRC polynomial would be very surprising, but not
> >inconceivable.
> >
>
> No more inconceivable that noise would produce a collision
> in a secure hash function. Various CRC polynomials have
> varying degrees of probability of "Noise" interacting badly.
> For primitive polynomials that are dense the probability is
> low.
That's for noise fitting some specific model. The
actual probability depends on the source, and we
don't usually know the true distribution of noise
on a given channel.
> Most MD style Hash functions use some sort of CRC type
> polynomial on the front end so this is an issue there as well.
Not true. SHA-1 has the W buffer up front, but the effect
is nothing like a CRC. In particular, the W-buffer
operations are reversible, so it alone never induces
collisions. MD-2 actually tacks on a checksum (good thing
too), but it's not on the front end; it's appended in the
back.
> >> 2) Hashing data for table lookups or other non-security oriented
> >> identification.
> >> 3) Random single bit error detection and burst error detection.
> >
> >I think any time I need a digest larger than 64-bits, I
> >would always use a cryptographic hash. I cannot envision a
> >case where I would believe I hit a 2^-64 shot (or even a
> >2^-32) before I would suspect foul play.
> >
>
> Sending 2^32*128bits of data is no longer just hypothetical.
> 15 hours of data on a 10Mbps ethernet will deliver that
> amount of data. With 32 bit CRCs some errors may go
> unchecked.
O.K, but I didn't disagree with going larger than 32 bits
(though 32-bits is in fact what Ethernet uses).
> 128 bit CRCs are easier to implement both in software
> and hardware than secure hash functions. Another
> thread suggested that a hash may be made as fast as
> a CRC but only at the expense of silicon space.
CRCs are certainly the winner in hardware speed. I don't
think the other poster was right that cryptographic hashes
can be as fast in hardware, at least not for the popular
ones such as SHA-1.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: A5/1
Date: Fri, 13 Oct 2000 08:57:34 GMT
I have a question regarding the stream cipher A5/1:
In order to obtain a really secure cipher, would it help to use the
original version of the A5/1 algorithm with longer LFSRs; e.g. with a
total length of 96 or 128 bits instead of 64?
The most powerful attack I have heard of is described in: "Real Time
Cryptanalysis of A5/1 on a PC" by Biryukov, Shamir and Wagner (FSE
2000). The attack presented in this paper makes use of a weakness of
the clocking taps, "which makes the register bits that affect the clock
control and the register bits that affect the output unrelated for
about 16 clock cycles".
Does anyone know how to overcome this weakness? My idea would be to
use one or two more taps for the clock-control.
Any comments would be helpful...
Andi
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Rijndael implementations
Date: 13 Oct 2000 09:13:03 GMT
David Eppstein <[EMAIL PROTECTED]> wrote:
+---------------
| [EMAIL PROTECTED] wrote:
| > Having "byte" defined as "set of bits that represent a single character"
| > seems like a really dumb idea to me.
|
| You've obviously never programmed a 36-bit architecture.
+---------------
Such as the venerable DEC PDP-10 -- in which the hardware supported bytes
of *any* length from 1 to 36 bits; in which plain ASCII text files
consisted of *7*-bit bytes (packed five to a word with one bit wasted)
and filenames passed to system calls were "SIXBIT" ASCII (six chars to
a word); in which at least one C compiler decided to use *9*-bit bytes
just so they packed evenly into words.
[But IIRC, we've already had this somewhat off-topic thread in this group
several times in the last year or so...]
-Rob
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Why trust root CAs ?
Date: 12 Oct 2000 17:11:58 -0600
In article <[EMAIL PROTECTED]>,
Doug Kuhlman <[EMAIL PROTECTED]> wrote:
> ...
>> I don't see why the banks just produce their own certificates and
>> publicly state their public key in the news papers, WSJ, etc. Then
>> there is no CA and you are absolutely certain that your bank is
>> providing the security they need to CTA with...
>>
>Oh, that'd be fun! Why should I trust the newspaper. It'd be much
>easier for "Joe's Discount Hacking Service" to run a few dozen
>fraudulant postings of public keys than to go through the trouble of
>spoofing a business, wouldn't it? Why would you trust your newspaper
>(or WSJ or ...) if you don't trust a CA who at least tries to verify the
>entity involved?
Why? Because when you need the key, you can go to several libraries
and check it for the last 5 years. You can pick libraries that your
adversaries are unlikely to have visited first.
Because except for the biggest outfits that don't need verifying, it is
even easier to fool the so called verifying of the CA's than printing
and distributing fake newspapers. Again, go look at Verisign's web pages
to see how trivial, easily fooled is verifying they do for all but the
biggest outfits that don't need any verifying.
However, there is a good reason to use a CA authority that has nothing to
do with snake oil verifying. While you can trust the WSJ or your local
newspaper somewhat more than CAs repository (how many keys could you
improve by distributing some unmarked cash?), it is a hassle to transfer
your bank's public key from a paper newspaper into your browser compared
to letting your browser ask a CA. In other words, a moderately trustworthy
automated repository of the public keys of outfits whose domain names and
IP addresses you can obtain from other, necessarily more trustworthy
sources is quite handy. While the overt reasons CAs give outfits to pay
$400 or more per year to publish their public keys are silly or worse,
that service does have value as a convenience to some of the outfits'
customers.
As has been pointed out repeatedly, those other sources of domain name
and IP address are more trustworthy than any current public CA because
they are the sources of the CA's information. Having a CA repeat a domain
name must be less trustworthy (albeit trivially) than if you asked the
registry or roots directly. And again, Verisign does absolutely nothing
with or about the real address of a web page, its IP address or addresses.
If you know that you want to talk to Amazon.com, then you don't need and
can't use help from a CA to tell you that you want http://www.amazon.com.
There is nothing any CA can do to keep you from being confused and possibly
defrauded if you go to http://www.amazon.net or http://www.amazon.org to
buy books. (I used amazon.net and amazon.org only for illustration.
I don't intended to say anything bad about Amazon Internet or Amazon
Online. I assume they're a fine, upstanding Internet service provider
and a reputable service organizaion. (But wasn't there some recent legal
activity about the amazon.org name that ended with Amazon.com losing?))
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Why trust root CAs ?
Date: 12 Oct 2000 17:21:45 -0600
In article <8s50bj$svn$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <8ru73v$abb$[EMAIL PROTECTED]>,
> ...
>CAs provide a service. You can take advantage of that service or
>you can roll your own....
"Rolling your own" CA amounts to about 60 seconds of work after you've
figured out what it's about, and you're a fool if you use any CA without
first doing that figuring out.
Common HTTP servers come with all of the stuff needed for a small CA.
For Apache, you need only following the easy instructions to run some
programs to create some files, put them where they belong (including secure
backups and so forth), and you're off and certificate authenticating.
That "rolling" is vastly less than the work needed to build (not to mention
maintain) even a trivial web site.
I did say "small CA," but an other than small HTTP server is more
non-trivial than an other than small CA. Worse, your HTTP server will
become other than small a lot sooner than your CA.
And no, contrary to advertisements from the commercial CAs, you don't need
more geographical or IP topological distribution for your CA than for your
DNS or HTTP servers. If your customers can't resolve your DNS names or
reach your HTTP servers, they won't be interested in chatting with your
CA system.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
Date: Fri, 13 Oct 2000 11:13:54 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: BlowFry...
Will Newland wrote:
>
> "Runu Knips" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Rob Marston wrote:
> > > To this end I have produced an 8bit version of BlowFish
> > > which for fun I have christened BlowFry.
>
> I told my wife I heard there's a "millenium edition" of
> Blowfish called 'BlowME'. She wasn't amused. Oh, well.
Windows, me ? Tux rulez ! ;-)
I still wonder why Schneier gave his algorithm this name.
------------------------------
Date: Fri, 13 Oct 2000 11:17:57 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Tom St Denis wrote:
> I am also writting a book (which will be free) about block ciphers
> where I will include descriptions + analysis of my ciphers (amongst
> other public ones such as Blowfish, RC5, IDEA and TEA). The book is
> slow going, I am on my chapter of "Cryptanalysis" right now and alot of
> work has to be done on the earlier chapters...
Oh, you're still working on it ? I've already thought you've given
it up. Cool thing ! :-)
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Why trust root CAs ?
Date: 13 Oct 2000 09:20:24 GMT
Vernon Schryver <[EMAIL PROTECTED]> wrote:
+---------------
| However, there is a good reason to use a CA authority that has nothing to
| do with snake oil verifying. While you can trust the WSJ or your local
| newspaper somewhat more than CAs repository (how many keys could you
| improve by distributing some unmarked cash?), it is a hassle to transfer
| your bank's public key from a paper newspaper into your browser compared
| to letting your browser ask a CA...
+---------------
Actually, not any more. There are lots of cheap hand-held bar-code
scanner/pens these days, the latest hyped use being to scan in URLs from
magazines so you don't have to type them!! Should be rather easy to print
the bank's public key in a paper newspaper in machine-readable form...
-Rob
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Date: Fri, 13 Oct 2000 09:23:34 GMT
Tim Tyler wrote:
> While hash functions take longer to evaluate in software,
> they often have a layered structure that allows hardware
> implementations to accept new inputs before the last
> inputs have been completely processed, allowing
> concurrent processing to take place.
>
> Consequently - while the area used is much increased when
> compared to a CRC - there's not anything like so much
> difference in throughput speed as a software engineer
> might expect.
What hashes are you talking about? In cryptographic hashes
such as SHA-1, there exist opportunities for parallelism but
the number of stages that must be sequential is a hardware
nightmare compared to a CRC.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Fri, 13 Oct 2000 18:10:54 +0800
Runu Knips wrote:
>
> Hmm your code looks good, but you have a macro S() and a variable
> S, thats confusing, and your macro S() implements a _R_orate
> (right) and your macro R() implements a _S_hift (also right)...
> but well its easy to fix that.
If you read the SHA-256 spec it uses the symbol 'S' for a rotate, and
'R' for a shift. I wonder why that is? And anyhow the code already
conforms to the test vectors (according to Tom), so I guess NIST knew
what they were doing when they used an apparently reversed notation.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Fri, 13 Oct 2000 10:21:40 GMT
In article <J5vF5.6458$[EMAIL PROTECTED]>,
"Paul Lutus" <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> > I have no problems with that. I just didn't see that in your
> > statements at the beginning of your posting. The light spot
> > IS moving faster than c, but that doesn't mean that any physical
> > object is doing that since the light spot at different places
> > is being made by different photons.
>
> With emphasis on "The light spot IS moving faster than c," it is
important
> to clarify that no photons are individually tracking this geometric
> relationship. I know you agree, I just want to emphasize this, because
some
> reading this may think that photons may exceed c so long as
information
> doesn't.
>
> The lighthouse effect is sort of a curved wavefront (imagine a
spinning
> firework throwing sparks out in a spiral), each part of which can
arrive at
> a target at whatever time dictated by the overall geometry. But that
> wavefront is composed of individual photons traveling at c.
>
> This is for the general reader, not you -- I know you understand this.
>
A double standard ? That sounds like a slide rule to me. :)
Sure, the I/O is not FTL.
But where is the computation taking place ?
Is it taking place with the beam projecting out to the image spot or
the reflected light coming back from the spot ?
The computation _is_ the spot, and it moves faster than light.
Having lots of spots amplifies your returns over the I/O
limitation. Otherwise quantum computers are a waste of time.
"You can't have your meat if you don't eat your pudding.
If you don't eat your pudding, how can you have any meat ?"
- Pink Floyd
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Challenge...
Date: Fri, 13 Oct 2000 10:20:05 GMT
I've got a challenge for anyone that is interested...
I have developed my own encryption system, and it is extremely powerful
and simple in it's intended environment. To see just how good the
system is, I have decided to use it in another way. I have used it as
simply as possible, and encrypted a short sentence. I do not know if
it is uncrackable like this - (probably not), but in it's intended
environment, it can be - it just depends how much effort you put in to
it. I'm saying nothing else at this time...
LKLUTHN_BROCDTRD_L_GHUYURNV__
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: More on the SDMI challenge
Date: Fri, 13 Oct 2000 18:36:45 +0800
Well, I've heard on Slashdot that SDMI has already been broken. Well,
it reassures me a little, knowing that what they want to do really is
impossible, but I really think that these fools at the RIAA need to be
taught a hard lesson. Let them adopt a standard, and let's see their
faces WHEN it is cracked. With their quixotic pursuit of such a secure
digital watermarking technique, and persistence in doing what is likely
impossible, they probably need to learn the hard way that the world no
longer works the way they've always assumed.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
Date: Fri, 13 Oct 2000 12:05:54 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Challenge...
[EMAIL PROTECTED] wrote:
>
> I've got a challenge for anyone that is interested...
>
> I have developed my own encryption system, and it is extremely powerful
> and simple in it's intended environment. To see just how good the
> system is, I have decided to use it in another way. I have used it as
> simply as possible, and encrypted a short sentence. I do not know if
> it is uncrackable like this - (probably not), but in it's intended
> environment, it can be - it just depends how much effort you put in to
> it. I'm saying nothing else at this time...
>
> LKLUTHN_BROCDTRD_L_GHUYURNV__
That wasn't so hard. It's quite a clever combination of encryption and
compression, but I got my Cray to work on it, and managed to tease out
the plaintext:
"I am relying on the secrecy of my algorithm to give me security.
Therefore, my data is at the mercy of anyone who can get hold of my
algorithm; for example, even a script kiddie with a disassembler could
read my stuff."
Publish your algorithm. Your security should be in your key.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
** 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
******************************
