Cryptography-Digest Digest #652, Volume #11 Fri, 28 Apr 00 09:13:01 EDT
Contents:
Re: Intel drops serial number (Arturo)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: A naive question ("Joseph Ashwood")
Re: Call for testing and evaluating a stream cipher program (Johny)
Re: public/private encryption keys and biometrics ("Lyalc")
Re: AEES 16 rounds ([EMAIL PROTECTED])
Re: OAP-L3: Secure, but WAY more dificult to use than other (Richard Heathfield)
Re: new Echelon article ([EMAIL PROTECTED])
Re: Karatsuba threshold (Jean-Jacques Quisquater)
Re: sci.crypt think will be AES? (Runu Knips)
S/MIME v2 Message Spec has 4 rules to step down in symmetric encryption (jungle)
Re: sci.crypt think will be AES? (David Blackman)
Re: Looking for a *simple* C Twofish source (Runu Knips)
Biometrics and public/private key encryption ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Crossposted-To: talk.politics.crypto
Subject: Re: Intel drops serial number
Date: Fri, 28 Apr 2000 07:26:46 GMT
On Thu, 27 Apr 2000 15:50:04 -0700, Roger <[EMAIL PROTECTED]> wrote:
>The article doesn't say anything about the random number generator.
>I couldn't find a press release at intel.com.
>
>http://yahoo.cnet.com/news/0-1006-200-1773089.html?pt.yfin.cat_fin.txt.ne
>
>Intel to phase out serial number feature
>By Michael Kanellos
>Staff Writer, CNET News.com
>April 27, 2000, 3:15 p.m. PT
>Intel will phase out its practice of stamping serial numbers on its
>processors with the next generation of chips, the final chapter in a
>public relations fiasco.
>
>Intel spokesman Howard High confirmed today that the company will not
>include serial numbers on the next generation of its processors,
>code-named Willamette, that will be released later this year.
Hurrah for them, seems like they finally saw the light. Of course, they
will not get upset if we check it out independently, hmm?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 28 Apr 2000 01:07:01 -0700
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >I entertained you when you suggested that you could predict
> >subsequent digits from the MixFile process you referred to to
> >see where it would lead.
>
> Oh, almost forgot to ask: have you sent me the challenge yet, as we
> agreed?
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOQhSWF+t0CYLfLaVEQLnzgCgqQt7XTtkpolMxoPtw7yrkqkDUHkAoOg4
> HhUQJBfhu0RVpocN+qiNQvfS
> =PCph
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
I am very busy these days. I will get to your posts as soon as
I can. Thank you.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: A naive question
Date: Fri, 28 Apr 2000 01:21:54 -0700
It seems to be a reasonable first assumption. Now I'm not
really sure where this is going so I may take the long way
around. the given values are probably off by a small delta,
I have ignored the value, I have also assumed that brute
force takes the maximal time, analysis onder the birthday
paradox, or half space probability will change the values
appropriately.
Assumptions:
k bits of true random data
n bits of non-random data, that is completely unknown,
and has formatting unknown to the attacker, but the attacker
can recognise a fully decoded message, but cannot identify
less.
a cipher that accepts at least k bits of key, using
random padding as needed on the end block, and that the
cipher offers perfect security on individual blocks
Actually this one I don't have to say too much on, it will
offer security of approximately n/(number of bitsper block
of cipher)*2^k, simply because the attacker must brute force
the cipher, and decode n/(num blocks) blocks of encrypted
data.
Assumptions:
k bits of true random data
m bits wide cipher, perfect in every way (brute force
only), that takes a k bit key or larger
n bits of plaintext, where an attacker can identify the
correct plaintext based on a single block
g blocks of cipher given n bits of plaintext
Ok, so an absolute max is of course, the brute forcing of
one block.
However to attack the entire system will take ~g * 2^k/g
attempts for full brute force
So it must offer strength of 2^k
The strength is obviously non-optimal (based solely on k),
but the maximal and minimal strengths (assuming perfect
ciphers) are so close together as to be effectively trivial,
I would have no problems with calling the maximal strength
2^k, or k bits.
Under the assumption that you do not have a cipher that can
handle the k bit key, things become slightly different.
Assumptions:
k bits of true random data
m bits wide cipher, where m is < k, perfect cipher
g blocks of plaintext
There are several cases here, in order to examine the curve
best I will set m at k-1, since all smaller sizes can be
simulated.
Method 1:
split key such that bits 0-(m-1) of k are used for block 0,
bit m of k is padded with 0's to form block.
if the full plaintext can only be recognised by retrieving
the full decryption.
The analysis is identical to the first class I gave, where
2^k security was offered, however if the attacker has enough
space to store double blocks, the security can be reduced to
2^m + 2^k-m for arbitrary m.
If the validity of a block of plaintext can be identified
based solely on that block, the security of the first block
is optimal (2^(k-1)), the second block has security of 2^1.
extending this without argument, I get that the first block
has security of 2^(k-b) the second block has security of 2^b
Method 2:
wraparound key, the bits of the key are reused in a known
order to create the keys for the two block.
As before, if the plaintext can only be recognised by having
the entire plaintext, the security is increased to 2^k,
unless the attacker has room to store the 2^overlapped
number of blocks, in which case the security is narrowed to
2^m+2^(k-m).
If the blocks can be identified individually, the security
is 2^m + 2^k-m
Basically the security is 2^m+2^(k-m) for all possibilities.
This is the first time I've actually sat down and considered
such, so please feel free to make whatever comments you
want, and yes I know I didn't go into as much depth on my
arguments as I would have liked, I don't have time right
now.
Joe
------------------------------
From: Johny <[EMAIL PROTECTED]>
Subject: Re: Call for testing and evaluating a stream cipher program
Date: Fri, 28 Apr 2000 08:41:26 GMT
Your program works well (and relatively fast), but still I have several
questions:
1. What are the guarantees that password length more then 20 letters is
enough?
2. Need source.
3. Need scientific approach (paper, analysis, ...)
Johny
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: public/private encryption keys and biometrics
Date: Fri, 28 Apr 2000 18:55:26 +1000
The biometric verification data is almost always processed in PC based
software. Ergo, the verification occurs in software - the typical reader
hardware is a passive element of the verification cycle (although it is an
active capture device)
As soon as the hardware scanning device put the captured data into any
untrusted processing environment (in this example a PC) the biometric is
suceptible to compromise, and potentially infinite reuse.
One trick can be to design the OS to not allow the user to do anything until
the trusted reader has verified the user's ID AND biometric. Of course,
this implies the reader can be securely and reliably loaded with the ID AND
biometric, or that the reader can securely communicate with a verification
centre trusted by both the Reader and the OS.
Lyal
Arthur Dardia wrote in message <[EMAIL PROTECTED]>...
>Lyalc wrote:
>
>> Interesting conjunction of ideas
>> "implemented properly" followed by links to PC software based solutions.
>
>How is the Compaq FIT system software-based? It of course needs the
obligatory
>fingerprint scanner in order to obtain data for the software to use.
>
>In addition, I wasn't referring to the Compaq FIT system in regards to
being
>"implemented properly;" rather, I was talking about using a person's
>fingerprint data as the passphrase to a key pair. (Depending on how much
data
>is taken, it may not be suitable to be used on it's own.)
>
>>
>>
>> Implemented, yes but properly?
>>
>> Hard to justify in the context of a security discussion group
>>
>> a couple of cents worth of musing
>>
>> lyal
>
>--
>Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
> PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES 16 rounds
Date: Fri, 28 Apr 2000 08:54:04 GMT
Manuel,
Thank you very much for your kindly reply.
It should be taken into account that former AEES 256-bit
implementation consists only from one round.
Last one is 16 rounds implementation. So one round performance is
comparatively to former implementation a bit better.
It would be no problem for me to implement this algorithm as a sample
application using MS Visual C++. But I can't do this without Assembler.
Assembler is my native language and I know a lot of hooks, which
improve performance.
Best regards.
Alex.
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Manuel Pancorbo schrieb:
> > <[EMAIL PROTECTED]> escribió en el mensaje de noticias
> > 8e6lle$p3n$[EMAIL PROTECTED]
> > > Performance with my IP II,267 Mhz, 128 Mb is 101 Kb/sec.
> > A bit slow, isn't it?
>
> But the last time he posted here it was only 64 KB/sec.
> So he improved the speed by more than 50% in such a
> short time. Cool :)
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 28 Apr 2000 10:02:40 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other
Tom St Denis wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Tom St Denis wrote:
> > >
> > > > So you should not waste anymore of your time conversing with me.
> > > > There are plenty of other suckers out there for your delectation.
> > >
> > > You see, you didn't respond to my questions. You just targteted *me*.
> > > How about you focus on your 'theory' and less the posters.
> > >
> > > Face it, your a troll.
> > >
> > > Tom
> >
> > Take my advice:
> >
> > Don't waste your breath.
>
> ARrg.. why don't you answer a real question?
>
I am reminded of Saruman, arguing with hobbits. It (such banter) was a
clear sign that, whatever mastery of his art he had once had, he had
lost it. Whatever majesty he might have commanded, he was now nothing
but an itinerant beggar.
The hobbits came out of it far better than Saruman, if I recall
correctly.
I'm not sure why anyone is wasting time arguing with this guy. He's
clearly bright but, equally clearly, he's either an idiot or an idiot. I
don't know much about cryptography, but I do know this: no source code,
no trust. No algorithm, no trust. Mr Szopa's security should be placed
in his key - not in his algorithm, his source code, or his incendiary
rhetoric. And his algorithm does not place all the security in the key.
If it did, he'd be falling over himself trying to prove it by showing
the algorithm and the source. Instead, he's doing his best to convince
us that he's an idiot and, on the whole, he's succeeding. Anyone who
hurls abuse at teenagers and flames Doug Gwyn in the /same thread/ is
clearly a few bits short of a byte.
A thread plonk is tempting, but on the other hand it's mildly amusing to
see just how deep a hole Mr Szopa can dig for himself before he finally
sees what he's done to his reputation.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
to go)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.newspapers,alt.journalism.print
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 Apr 2000 09:52:50 GMT
On Tue, 25 Apr 2000 16:51:12 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] wrote:
>> It's obvious that the U.S. has been using the capabilities of Echelon
>> and humint assets for years to scoop up economic information and pass
>> it along to specific U.S. corporations.
>
>It is far from obvious. What concrete evidence do you have?
I have asked you before not to cut newsgroups Mr. Gwyn, and cited the
reason for not cutting them. Continue to cut them only if you don't
wish an answer, or if for some reason you don't want others to comment
on the subject. This thread did not start solely in sci.crypt and you
did not start it.
To find your answer, reread the thread. I won't repeat myself.
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Subject: Re: Karatsuba threshold
Date: Fri, 28 Apr 2000 13:44:50 +0200
In the 80's I did a lot of experiments (with the help of JP
Delescaille and F. Heymans) about the possible
use of the Karatsuba method.
These implementations were never published (I was working for
Philips Labs) but are mine today (if I can recover it from the tape :-).
It was used by an interactive program the name is vli
(very large integers: some kind of a modest ancestor of gp).
It was working on VAX and SUN.
The main ideas were the following ones:
- use of assembly:
- use of optimized code (using a "classical method") for
multiplications and squarings for 64*64-bit integers,
128*128-bit integers, aso:
it is like using a virtual multiplier (the physical one is maybe
composed of shift and add, or 32*8 bits, aso):
- introduce 2 thresholds:
- the first one is the number of levels in use for Karatsuba:
- the second one is the multiplier in use:
we introduced the following notation:
mult(operand, Karatsuba, multiplier)
where "operand" means the length of the operands,
"Karatsuba" means the number of levels in use (0, 1, 2, ...),
"multiplier" means the length of the operands for the optimized
code
Example: mult(256, 2, 64) means a procedure for the multiplications
of operands of 256 bits using 2 levels of Karatsuba (with possibly
optimization of the symbolic expression for that) and a "virtual"
multiplier for numbers of 64 bits:
- compute symbolically several levels of Karatsuba (using MACSYMA)
with variants for Karatsuba: several variants were used together
for different parts of the same operation:
- use of MACSYMA for optimising the obtained formulas:
- integrating the relevant part of codes in one procedure:
- the resulting code was optimized (removing some redundant registers,
modifying the order of operations, unrolling if necessary,
taking into account the cache, ...).
Some results (sorry I don't have all results in hand):
(for SUN-4 and VAX 780)
mult(128, 1, 64) was a little better than mult(128, 0, 128),
mult(256, 2, 64) is really better than mult(256, 0, 256),
mult(> = 512, 1, 256) is nearly always better than
mult(>= 512, 0, 512).
If I remember correctly Jean Vuillemin (now at ENS, Paris) and people
from LAAS (Toulouse) did also a lot of experiments and published it
but our results were better :-(
Latter we did the same work for some smart card. Around 1995 I did
a design for a coprocessor with the use of Karatsuba in mind.
It was never used (to be published?).
------------------------------
Date: Fri, 28 Apr 2000 13:56:47 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Tom St Denis wrote:
> Paul Koning wrote:
> > Runu Knips wrote:
> > > Tom St Denis wrote:
> > > > Why I like Twofish. It's fast, it's compact, it's versatile (speed/size
> > > > tradeoffs), it's designed sanely. It's also very good choice for
> > > > hardware. It's also secure the best attack breaks (without whitening)
> > > > only 6 rounds and doesn't work against the full algorithm.
> > > Hey another Twofish fan ! :)
> > > I'll like it most of all AES candidates, too. You've forgot another
> > > point: its the AFAIK only one which is free NOW (no matter if it
> > > will be the AES winner, or not).
> > No; I think the same is true for Rijndael and Serpent.
> > I have a silly reason for liking Rijndael -- the name... :-)
> My reasons for liking Twofish extend to the name too. In reality I
> think all five winners are good ciphers, but Twofish is just catchier.
Funny reason. No, I just liked it most because it was the
only one which explicitly stated it is free, patent free,
and again its free, and I liked the algorithm because it
was a neat combination of well-known and new techniques
and its so well scaleable for your needs. For example,
my own, optimized for speed implementation requires more
than 4KB of space for the key schedule, while you can go
along with far, far less.
Well, and another reason why I like it so much: I didn't
studied the other ones too well yet *giggle* ;-)
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: S/MIME v2 Message Spec has 4 rules to step down in symmetric encryption
Date: Fri, 28 Apr 2000 08:04:02 -0400
at win95 + netscape v47/128 bit, after explicitly excluding all but one cipher
[ rc2/128 bit ] for s/mime encryption, received message, Netscape is reporting
as been encrypted by the algorithm 168 bit DES-EDE3-CBC & not the one that has
been selected ...
how this happen ?
this cipher has been excluded from use at encryption process ...
S/MIME v2 Message Spec has 4 rules to step down in symmetric encryption, but
the rules are for ambiguity only situations ...
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Date: Fri, 28 Apr 2000 22:18:15 +1000
Runu Knips wrote (about Twofish):
> Funny reason. No, I just liked it most because it was the
> only one which explicitly stated it is free, patent free,
> and again its free,
Serpent and Rijndael are also completely free. This is stated quite
explicity on their webpages.
------------------------------
Date: Fri, 28 Apr 2000 14:18:01 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Looking for a *simple* C Twofish source
[EMAIL PROTECTED] wrote:
> I see your point about Twofish being an engineer's encryption
> algorithm, but thousands of programmers will need to integrate it into
> their systems at some point, wouldn't they ? whether it's an
> engineer's encryption or a marine biologist's encryption, I think it
> should come with a pseudo-code listing.
Thats the typical problem. If you're a programmer, program
code is the definitely easiest thing to understand. But not
for a mathematican.
I would still suggest to study the twofish implementation
in the CryptoBag. Its really easy. If one combines it at
some places with the runtime table generation routines in
brian's code, I think one would get a really small version
which should be compact enough for your needs. Hopefully.
At least Twofish has been designed this way, that one
can implement it on microcontrollers or in hardware.
------------------------------
From: [EMAIL PROTECTED]
Subject: Biometrics and public/private key encryption
Date: Fri, 28 Apr 2000 12:28:05 GMT
Odd, my message dissapeared. Posting again.
I am trying to find any information on companies that support
public/private key encryption using biometrics instead of pass phrase
authentication.
Anybody know of any such company or of any that support SDKs (software
development kits) with thier encryption products so that we can write an
application that will accept biometrics instead of passphrase or
password authentications?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
