Cryptography-Digest Digest #359, Volume #12 Fri, 4 Aug 00 19:13:00 EDT
Contents:
Re: New block cipher for the contest (Mark Wooding)
Re: Applications for One-Way Function? (Mark Wooding)
Re: New block cipher for the contest (Runu Knips)
Re: Digital Certificates and Key Lengths (DJohn37050)
Re: New William Friedman Crypto Patent (filed in 1933) ("Douglas A. Gwyn")
Re: New William Friedman Crypto Patent (filed in 1933) ("Douglas A. Gwyn")
Re: counter as IV? ("Douglas A. Gwyn")
Re: Elliptic Curves encryption (Roger Schlafly)
Microsoft Certificate Server (Kashif Hassan)
Re: Digital Certificates and Key Lengths (Kashif Hassan)
Re: Digital Certificates and Key Lengths (Kashif Hassan)
Re: New William Friedman Crypto Patent (filed in 1933) (Jerry Coffin)
Re: RC5 / 4 (David Hopwood)
Re: Elliptic Curves encryption (DJohn37050)
Re: analogies, (John Myre)
Re: Software package locking (Mike Andrews)
Re: New William Friedman Crypto Patent (filed in 1933) (Bruce Schneier)
Wanted - links. (Ichinin)
Re: Cracking RC4-40 in FPGA hardware (Bill Unruh)
Re: Cracking RC4-40 in FPGA hardware (Bill Unruh)
Multiple encryption passes (AllanW)
Re: Elliptic Curves encryption (Chris Rutter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: New block cipher for the contest
Date: 4 Aug 2000 17:16:24 GMT
Martin 'SirDystic' Wolters <[EMAIL PROTECTED]> wrote:
> Could somebody tell me the URL with
> the ciphers submitted to this contest?
http://www.wizard.net/~echo/crypto-contest.html
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Applications for One-Way Function?
Date: 4 Aug 2000 17:14:21 GMT
Ed Suominen <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Assume the existence of a one-way function with the following
> properties:
>
> 1. For any input value in the space {0,2^N}, there is a unique but
> unpredictable output value in the same space, {0,2^N}.
I assume that this notation describes the integer interval [0, 2^N) \cap
Z (i.e., the space of N-bit values), rather than being a set of two
elements. I don't believe that any permutation on a set of two elements
could have property 3. ;-)
> 2. Each output value corresponds to only one possible input value (no
> collisions possible).
>
> 3. It is very easy (and very fast) to compute an output value from an
> input value, but computationally infeasable (e.g., 2^128
> possibilities) to compute an input value from an output value.
>
> What sort of crypto applications are there for such a function,
> besides storing transformed passwords for verification against input
> passwords?
You could use it as the F-function in a target-heavy generalized Feistel
network to build a block cipher. (Concatenate a subkey and one of three
subblocks, push them through the function, and mix the output with the
other two subblocks; then rotate.)
You could use it as a public identifier for keys. Assuming that all of
your keys were in the domain of this function, the image of a key
provides no information about the key itself, so it's OK to use the
image in public data to identify the key. The absence of collisions for
the key identifiers could be an advantage over the usual practice of
using a collision-resistant hash function if collisions are really bad
for some reason.
That's all for now. I'll probably come up with some more later.
The usual one-way function for use in these sorts of contexts is
exponentiation in some finite cyclic group in which the discrete
logarithm problem is hard. It's not what you might call `fast', but it
is secure.
-- [mdw]
------------------------------
Date: Fri, 04 Aug 2000 19:25:21 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New block cipher for the contest
Martin 'SirDystic' Wolters wrote:
>
> Could somebody tell me the URL with
> the ciphers submitted to this contest?
http://www.wizard.net/~echo/crypto-contest.html
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Digital Certificates and Key Lengths
Date: 04 Aug 2000 17:45:18 GMT
The 512-bit RSA challenge has been solved and therefore use of 512-bit RSA is
considered insecure.
Don Johnson
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 4 Aug 2000 16:29:08 GMT
wtshaw wrote:
> When the patent process is used to enable government control at the
> expense of the inventor, this is contrary to reasonable action. NSA
> should not expect to extend its control by virtue of beaucratic planned
> inefficiency in addressing an inventor's generated works; their tentacles
> are not to be enhansed at the cost of someone elses testacles.
Bureaucratic inefficiency has nothing to do with it,
and WFF was awarded a large sum in compensation for
not being able to profit directly from classified
patents. Perhaps you should check your facts before
ranting.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 4 Aug 2000 16:31:57 GMT
Bruce Schneier wrote:
> Here is what Whit Diffie said about the M-134 ...
> He calls it one of the worst crypto machines ever designed.
On what grounds? The M-134-C variation (incorporating Rowlett's
modification) was one of the *most successful* crypto machines
ever designed.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: counter as IV?
Date: Fri, 4 Aug 2000 16:42:42 GMT
Bodo Moeller wrote:
> David A. Wagner <[EMAIL PROTECTED]>:
> > Using a truly random IV eliminates this vulnerability. That's why I
> > recommend to use an unpredictable, random IV, and not, e.g., a counter.
> Does it really have to be a *truly* random, *unpredictable* IV?
> What about applying a publicly known PRF to counter values?
Indeed, from other parts of this thread, that seems sufficient,
if the PRF is applied to the combined counter *and* secret key,
and if the PRF cannot feasibly be inverted to find the key.
So the PRF could be some standard Message Digest function, e.g.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Fri, 04 Aug 2000 10:53:49 -0700
DJohn37050 wrote:
> DL and EC use public primes, RSA uses secret primes. This means the prime code
> for DL/EC can be OUTSIDE the security boundary and the primes can be audited in
> a straightforward manner. The prime code for RSA must be INSIDE the security
> boundary and auditing the generation of such primes is difficult.
Fortunately, most people do not want their secret keys audited.
------------------------------
From: Kashif Hassan <[EMAIL PROTECTED]>
Subject: Microsoft Certificate Server
Date: Fri, 04 Aug 2000 14:07:26 -0400
Does anyone know how to setup a 1024 CA using NT 4.0(IIS4.0, cert srvr
1.0)?
Whenver I install the certificate server component, it seems to(by
default?) setup a 512 CA? And can't seem to find any option of changing
it to 1024.
all possible help is appreciated.
thx
Kashif
------------------------------
From: Kashif Hassan <[EMAIL PROTECTED]>
Subject: Re: Digital Certificates and Key Lengths
Date: Fri, 04 Aug 2000 14:02:30 -0400
Ok, this would not be a secure connection? Would it be more, less,
equally secure as a 512 CA issuing a 512 cert?
Mark Wooding wrote:
>
> Kashif Hassan <[EMAIL PROTECTED]> wrote:
>
> > Does it make sense to have a 512 CA issue 1024 certs?
>
> Not really. It means that the 1024-bit key can be replaced by a dummy
> one for the cost of factoring a 512-bit number, which is (just about)
> within the realms of possibility. Once that's done, CA certs can be
> forged, so the adversary can set up a man-in-the-middle attack with his
> spangly new certificate.
>
> -- [mdw]
------------------------------
From: Kashif Hassan <[EMAIL PROTECTED]>
Subject: Re: Digital Certificates and Key Lengths
Date: Fri, 04 Aug 2000 14:04:17 -0400
Does this mean that a 512 CA cert(regardless of what type of cert it
issues) is obselete?
How does the CA cert related with the issued cert? Is there some sort of
interaction?
DJohn37050 wrote:
>
> The 512-bit RSA challenge has been solved and therefore use of 512-bit RSA is
> considered insecure.
> Don Johnson
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 4 Aug 2000 13:06:02 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> >William Friedman filed a patent application for an Enigma-like
> >encryption device in 1933. The Patent Office awarded the patent this
> >month:
> >
> > http://www.patents.ibm.com/details?&pn=US06097812__&s_all=1
> >
>
> Hmmm ... does someone at IBM have a sense of humor or
> did the patent office hold a patent due to National Security Issues?
> Has this been checked against any other databases?
I just checked on the US PTO web site, and it gives the same
information as IBM does. In case anybody cares, the URL is:
http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2
=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1
='6,097,812'.WKU.&OS=PN/6,097,812&RS=PN/6,097,812
If you decide to use it, that's supposed to be one long string.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Date: Fri, 04 Aug 2000 10:08:03 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RC5 / 4
=====BEGIN PGP SIGNED MESSAGE=====
John Myre wrote:
> tomstd wrote:
> <snip>
> > Note: RC5 is the holy grail of RSA so unless you want to start a
> > war with them I would avoid it.
>
> Hm. This analogy isn't exactly right; a "holy grail" is something
> you want very badly, but don't have yet. And maybe, it's not possible
> to get it. Like, say, a proof of security for SHA.
>
> What is something that you have, and are jealously protective of?
"Crown jewels." (Not that this is really appropriate for RC5.)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYqH2jkCAxeYt5gVAQFBFwgAmD5kAYYYZUISUqwKbgik7NAHhfv+U0Oc
gUObHmSG4x/tV6DXAhFM0xX4BVzvZx+Na/NAo8nV8V+I1aoh2Nze4KQcFLv+2FYr
vH13sc6zLdncdFOwcJwezHziVvmHrK6/XG8CdrJirfiUDyj09W6hnnrr/rGcASFD
99GEqNG6tGY++22hp/3Mka4MJXzhtqY7O4LMuk5W8q7nh/J0209lT0flVQX28fMs
Fgp5Pi5/dGiA/9Nzpl4m4cfu1mqZh3u57je3amkerxjpPa+EG5Hn5gDT3qGFGGZb
eFtdnWqvSWLXwf/HpipZg8dogMWHDEqfcn9rcoxlwKtxgRenQJqIqA==
=8DvM
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 04 Aug 2000 19:58:14 GMT
Subject: Re: Elliptic Curves encryption
Perhaps Roger was just being witty, but in a dispute, an audit trying to
establish what happened may be useful and/or required. And even without a
dispute the owner might wish to have some confidence that the key generation
did not go awry somehow. I know that if I was doing large value transactions,
that is what I would wish.
Don Johnson
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: analogies,
Date: Fri, 04 Aug 2000 14:13:29 -0600
> "Crown jewels."
Excellent! Thank you.
JM
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: Software package locking
Date: Fri, 04 Aug 2000 20:58:25 GMT
Scripsit AllanW <[EMAIL PROTECTED]> about uniquely identifying
computers:
: First, if the computer has an Ethernet card use it's ID.
: Every Ethernet card ever manufactured has a unique ID
: encoded in it. Microsoft's GUID concept uses the
: Ethernet card's ID whenever possible. Many computers have
: an Ethernet adapter -- even some computers not on a local
: network have one, because they are pre-packaged deals that
: happen to be used in the wrong environment. If I want to
: get DSL at home, the phone company will connect to an
: Ethernet adaptor.
Many (though not all) Ethernet cards support a "LAA" (Locally
Administered Address) that can be assigned by the administrator.
We use LAA here at $ORKPLACE to give the location of the
machine based on a simple coding scheme. There is _nothing_
to prevent one of our administrators from screwing up and
plugging the same LAA into multiple Ethernet adapters, and
indeed that has happened.
Furthermore, one vendor shipped a _large_ number of Ethernet
NICs with the same burnt-in address within the last few years.
Since many of them went to the same customer (and wound up on
the same LAN segment), this caused headaches aplenty.
: Second, DON'T DO IT! What happens if my Ethernet adapter
: goes bad? I go buy a new one, and sigh with relief that
: I'm finally "up and running" again. But then your program
: fails! Or, I buy a new fast computer, complete with
: peripherals, and then I copy all data from my old hard
: drive to the new system. I may have to re-install the OS,
: but all the application programs are still working fine...
: except for yours.
What he said. We've had precisely these problems here at work,
many of our design technicians and engineers use programs
licensed for specific computers by serial number.
: If you use anything else about the user's computer except
: for the Ethernet address, you'll still have the same
: problem when I upgrade computers. Just don't do it! The
: extra money you spend making your program secure could
: be spent on advertising to increase your sales and show
: everyone what a good program you have. You'll make more
: money and everyone will be happy.
Again, what he said. The money you may potentially lose in
piracy will be more than offset by the ill will you'll
accumulate when your program won't run for a legitimate
user.
--
You are in a maze of twisty little protocols, all the same.
------------------------------
From: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 04 Aug 2000 16:23:23 -0500
On Wed, 02 Aug 2000 16:42:24 -0500, Bruce Schneier
<[EMAIL PROTECTED]> wrote:
>William Friedman filed a patent application for an Enigma-like
>encryption device in 1933. The Patent Office awarded the patent this
>month:
>
> http://www.patents.ibm.com/details?&pn=US06097812__&s_all=1
Could this be an M-228?
http://home.ecn.ab.ca/~jsavard/crypto/te0305.htm
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Wanted - links.
Date: Fri, 04 Aug 2000 23:15:52 +0200
Hi.
Anyone feel like sharing links to documents about
key-specific algorithms (Key expansion, criterias
etc) also about key scheduling and other
"Key"-topics. (pun intended)
Thanks in advance,
Glenn Larsson
Novice Cryptodude
_______________
(My Email provider will sue your butt of if you
send me spam.)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: 4 Aug 2000 21:33:34 GMT
In <8mcbbp$[EMAIL PROTECTED]> "Paul Morris" <[EMAIL PROTECTED]> writes:
>Paul mentioned that RC4-40 is used in exportable web browsers (presumably as
>part of the SSLv3) and for password protected files in Microsoft Word.
>Although RSA's site states that RC4 is considered strong, Paul mentioned
>that it could be broken in 'a few months' with a PIII. Given that RSA
>consider it strong are there any other high profile uses for RC4-40? I'm
>very much looking for some 'wow factor' here!
There is a difference between RC4 and RC4-40, in that the latter is
easily attacked via exhaustive search of the password possibilities.
2^40=10^12 which is not very many possibilities. Ie, although blowfish
is considered unbreakable, blowfish-2 (ie using a 2 bit password) is
breakable on an abacus.
>this? Given my limited (but burgeoning) understanding of crypto I would
>assume that a brute-force attack like this would require the attacker to
>have both ciphertext and plaintext. If this is the case it makes a
>transaction using RC4-40, where the key used is a session key, impossible to
>break since even if one message is compromised the next transmission will
>use a different key. Or am I on the wrong track?
You need some information about the plaintext. Eg, the fact that it is
all ascii would be enough. ( a messages with all bit 7s equal to zero is
highly unlikely at random, but highly likely to be an ascii messages).
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: 4 Aug 2000 21:36:16 GMT
In <_Wii5.605$[EMAIL PROTECTED]> "CMan" <[EMAIL PROTECTED]> writes:
>The problem is that RC4 is not really amenable to parallel hardware
>solutions because of the swapping that is a fundamental part of the cipher.
A brute force on RC4 is highly amenable to parallel hardware, as you
simply have each piece of hardware search a separate key space.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Multiple encryption passes
Date: Fri, 04 Aug 2000 22:18:18 GMT
A month or two ago, I posted a question here about taking
data that had already been encrypted and encrypting it
again with a completely different algorithm. The general
concensus seemed to be that the strongest encryption
might not be strengthened any further by doing this, but
it shouldn't be weakened either. Someone even pointed
out that if the second encryption somehow did make the
first one weaker, then it couldn't have been very strong
in the first place, because the second one is partially
decrypting it!
I am also aware of discussions about the speed of
encryption algorithms. We always need to have SOME concern
over how quick our encryption and decryption are, for
simple practical reasons. Suppose there was such a thing
as an "absolutely perfect" encryption, meaning that nobody
but the recipient could ever hope to break it. But if it
took 10 years to encrypt the message and 10 more to decrypt
it, nobody would ever use it, right? So we can't let our
encryption program get TOO slow.
On the other hand, making sure that even fast computers do
take a few seconds to decrypt a message is a good idea
because it makes brute-force attacks harder. Assume that our
attacker is not the NSA, but instead is a hacker at home
with a 1GHz Pentium. Even if our key is only 32 bits long,
if it took our hacker 1 full second before he could tell if
his brute-force guess was accurate, the attack could be said
to fail.
My proposal is to use more than one pass through the data
when encrypting it. The first pass would take the plaintext
and produce the first ciphertext, which I will call C1.
Nothing in C1 would indicate which algorithm was used to
create it. Then the second pass -- using a completely
different method of encryption -- would encrypt C1 into C2.
Again, nothing in C2 would indicate which type of encryption
was used. And so on until we feel that the data is secure
enough.
One thing I haven't yet figured out is the practical aspects
of key generation. We could use the same key for each of
the encryption passes, perhaps with some fixed mutation
between them. Or, if we're getting keys by hashing input
from the user, we might ask the user to enter a different
passphrase for each pass of encryption, and reject any
attempt to use the same passphrase.
In any case, however we're generating keys would also be
used to select which encryption algorithm was used in the
first place. For instance, suppose we have 16 different
algorithms to choose from. We could generate a 44-bit
key, then use the first 4 bits to select an alrogithm and
pass the other 40 bits to that algorithm as the key.
We might add refinements, such as not allowing the same
algorithm to be used more than once or twice, or insisting
that one algorithm we trust to be hard to decrypt is
included at some point in the encryption process.
Then, knowing the key(s) (or the passphrase(s) used to
create them) would not only supply data for the decryption
process, but would also select which decryption was used,
in the opposite order that the message was encrypted in
the first place.
The point here is that any attempt to decrypt the message
would not only have to break each of the N passes, but it
would also have to figure out which one of the 16
different algorithms was in use. And the order to use
to decode the message would be different for every message
cracked, assuming we used different keys for each message.
Naturally, this whole process would be slower than any one
encryption method. But in cases where speed is not a huge
concern, this should still process quickly enough for most
purposes. And the only way to do brute-force attacks would
be to try different passphrases with practically the same
program used by the recipient; that is, the program would
have to know how to turn key bits into algorithm selectors.
What do you think?
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Chris Rutter <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Fri, 4 Aug 2000 23:27:36 +0100
Mark Wooding <[EMAIL PROTECTED]> wrote:
>> >> How about this: That's a stupid request.
>> >
>> >Now prove that this is a fact. ;-)
>>
>> Self evident.
> Are you asserting this as an axiom? Very well; I'll assume the opposite
> and we can happily live in similar but different universes... ;-)
Uh-oh. That sounds Godelesque.
c.
------------------------------
** 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
******************************
