Cryptography-Digest Digest #503, Volume #13 Fri, 19 Jan 01 23:13:01 EST
Contents:
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Dynamic Transposition Revisited (long) ("Matt Timmermans")
Re: Why Microsoft's Product Activation Stinks ([EMAIL PROTECTED])
32768-bit cryptography ("lemaymd")
File Transfer with Rijndael ("Marcin")
Re: Novell Netware authentication (David P Jablon)
Re: 32768-bit cryptography (David Schwartz)
Re: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP) (David A Molnar)
Re: Kooks (was: NSA and Linux Security) (Boris Kazak)
Re: Why Microsoft's Product Activation Stinks (Russ Lyttle)
Re: 32768-bit cryptography ("Paul Pires")
----------------------------------------------------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sat, 20 Jan 2001 01:14:30 GMT
In article <[EMAIL PROTECTED]>,
"Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote:
> zapzing wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > "buddy_holly" <[EMAIL PROTECTED]> wrote:
> > > here are some good free PC operating systems:
> > > (you can burn these ISO images with most cd-r software and a cd
> > burner)
> > >
> > > Red Hat Linux 7.0:
> > >
ftp://ftp.redhat.com/pub/redhat/current/i386/iso/7.0-respin-disc1.iso
> > >
ftp://ftp.redhat.com/pub/redhat/current/i386/iso/7.0-respin-disc2.iso
> > >
> > > FreeBSD 4.2:
> > >
> >
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/4.2-install.i
> > so
> > >
> >
> > Most people. like me, won't want to deal
> > with the installation hassles of Linux, so
> > the danger remains that a national crisis
> > could be made much worse by MS's Product
> > Activation scheme.
>
> Linux is EASIER to install than windows.
>
> Boot up the install program...it installs ALL of your hardware drivers
> in one pass...AND about 1,500 applications.
Hmm.. which "flavor" of linux are
you talking about? And on which
machine?
> all that with ONE reboot.
>
> Doing the equivalent on Windows would take you over a month.
Except that most people never do it at all.
It comes on the machine. Can't get any
easier than that!
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 20 Jan 2001 01:41:33 GMT
I do think that this makes for an interesting cipher. It is "perfect" in
exactly the same way as OTP is perfect. The benefit over OTP is that it's
somewhat resistant to bit-flipping, though not as resistant as block ciphers
are.
If you have an unbreakable keyed RNG, though, then there are lots of easy
ways to make secure ciphers. It would take a lot of work to show that the
system is secure with a real RNG, though. In particular, this bit doesn't
work:
> Known-plaintext attacks would be a first step in an attempt
> to attack the RNG as in a stream cipher. But with Dynamic
> Transposition, known-plaintext does not disclose the
> enciphering permutation, because a plethora of different
> bit-permutations will produce exactly the same ciphertext
> from exactly the same plaintext. A successful attack
> would thus require some way to distinguish more probable
> permutations from less probable ones. Such an attack would
> seem to be avoided by proper shuffling.
If you don't know anything about the RNG, then there's no such thing as a
known-plaintext attack. That works for XOR stream ciphers too. When you do
know something about the RNG, then a known-plaintext attack against a
dynamic transposition cipher does not necessarily start by guessing the
permutation for a single block.
With 4096-bit blocks, one block of known plaintext gives you over 4000 bits
of information about the state of the generator -- there may be 2^39000
permutations that give you the same output, but there are 2^43000 possible
permutations, so you get 4000 bits or so about the state of the generator
itself, and this is only marginally less that you would get with an XOR
stream cipher and a block of the same size. In this case, though, the
actual number of plaintext bits you need to make the block might be less
that 4096.
How useful is this information? As with an XOR combiner, it depends on the
RNG. The real question is whether or not I can extract a reasonably concise
statement about the generator given this information, and whether I can
combine such statements from multiple blocks until I know the generator
state.
In theory, your combiner is like using the plaintext to select some
generator bits that you throw away. It's probably a good idea for
amplifying the security of a stream cipher, but it's not provably secure in
any strong way, and there are easier/faster ways to do it that also let you
choose how many bits to toss (90% is a lot).
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sat, 20 Jan 2001 01:37:08 GMT
In article <[EMAIL PROTECTED]>,
Gunner <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Jan 2001 13:46:49 -0500, "Mysterion" <[EMAIL PROTECTED]>
> wrote:
>
> >Sounds like Microsoft is determined to shoot themselves in the foot.
>
> Give the boyz at Warez.com a couple weeks...no problem....lol
Gee, Gunner. I dunno. An entire week?
I wonder if a backup copy of the harddrive would need to be activated?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "lemaymd" <[EMAIL PROTECTED]>
Subject: 32768-bit cryptography
Date: Fri, 19 Jan 2001 19:44:35 -0600
To all interested:
Bermuda Triangle 2001 is an extremely fast, easy-to-use and secure
cryptography engine. It is based on a new, 32768-bit algorithm of the same
name. Algorithm details can be found at my site as well as a software
product that uses the algorithm, Bermuda Triangle 2001 Golden Edition. I
also have a free cryptography engine that uses a similar (but incompatible)
algorithm available for download. Visit the site at:
http://www.bermudatriangle.f2s.com/
These software packages are written entirely in 32-bit, win32 assembly
language and I can encrypt or decrypt an 8.4MB file on my Pentium(R) 166 in
8 seconds. Please give me your feedback!
------------------------------
From: "Marcin" <[EMAIL PROTECTED]>
Subject: File Transfer with Rijndael
Date: Fri, 19 Jan 2001 21:01:41 -0800
Hello,
I'm working on a way to securely transfer files over on insecure medium.
One of the ways I'm considering is to pass the file through a stream that
would create an encrypted file like so:
1st - 4th byte : total number of blocks (16 bytes each)
5th byte : number of bytes used in the last block
6th - 21st byte : message digest MD5
22nd - X : the file data
X - Y : random padding to make Y equally divisible by 16
Then symetrically encrypt each block with Rijndael in CBC mode, both sides
already share the encryption key. This resulting encrypted 'file' can be
streamed to the recipient.
The number of blocks is for convenience to make the protocol simpler, so
when a bunch of data is coming, it knows right away how much more to expect.
The message digest is purely for error detection, and the random padding is
only used to make the data fit into integral number of cipher blocks. Can
anyone see a problem with this method? I'm easily exposing the first 5
source bytes of the encrypted block, but with Rijndael, knowing the source
bytes doesn't help the potential attacker. Am I right here?
Thanks,
Marcin
ps. Thanks Benjamin for suggesting SHA256, is there a free Java source
available somewhere?
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Novell Netware authentication
Date: Sat, 20 Jan 2001 02:25:53 GMT
In article <[EMAIL PROTECTED]>,
Chris Johnson <[EMAIL PROTECTED]> wrote:
>
>Does anybody have any information on the authentication protocol used to
>log a user into a netware server ?
The NetWare V3 and V4 authentication protocols are described in
Kaufman, Perlman, & Speciner's "Network Security: Private
Communication in a Public World".
Some very brief comments on this and other (ahem) sub-optimal
password-authentication protocols is at
<www.integritysciences.com/obsolete.html>
-- dpj
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Fri, 19 Jan 2001 18:34:05 -0800
lemaymd wrote:
>
> To all interested:
> Bermuda Triangle 2001 is an extremely fast, easy-to-use and secure
> cryptography engine. It is based on a new, 32768-bit algorithm of the same
> name. Algorithm details can be found at my site as well as a software
I won't trust it until the 65,536-bit version comes out.
DS
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP)
Date: 20 Jan 2001 03:04:22 GMT
Kenneth Almquist <[EMAIL PROTECTED]> wrote:
> the possibility of related key attacks and prevent them. As a user of
> cryptographic primitives, I would much rather have the designers of
> the primitives do the hard work of making the primitives strong, so
> I don't have to worry about working around the weaknesses in them.
This is a perfectly reasonable attitude. I don't think anyone *likes*
nontrivial relations holding over their hash functions, such as the one which
holds over MD5. At the same time, there is some difficulty still in figuring
out just what makes a hash function "strong."
The early articles I've read, when a hash function is used, tend to just
call it "random enough" (e.g. Fiat-Shamir's Crypto '86 paper). Then you
have the notions of collision-freeness both strong and weak which appeared
in conjunction with digital signatures. The first article of which I'm aware
which discussed the general problem of how to define the security we want from
a hash function in is due to Ross Anderson.
"The Classification of Hash Functions"
Circenester 93
http://www.cl.cam.ac.uk/ftp/users/rja14/hash.ps.Z
In it, Anderson points out that collision-freeness is too weak to capture all
the properties we might want from hash functions. Further he gives examples to
show that some of these other properties are independent of
collision-freeness. In particular, Okamoto's notion of correlation-freeness is
proved to be stronger than collision-freeness. It closes with musings on
whether there can be a universal property of hash functions which implies all
the other properties we might want...
...in other words, whether we can give a general definition of what it
means to be a "good hash function."
I don't know why, but it doesn't seem like this paper was much read. If you
read it today, it's pretty *eerie* how it anticipates the recent spate of
papers on the random oracle model. In particular his remarks on writing down
explicit relations which security depends upon seem to capture what several
recent attempts at "removing random oracles" have actually done - first prove
security in the RO model, then write down explicit relations needed, finally
show that functions for which finding those relations is hard exist.
>> 2. The random oracle model is flawed.
Yes.
Canetti, Goldreich, and Halevi showed that if you allow a signature scheme
which makes use of the "description" of an oracle, you can build a signature
scheme which is secure in the random oracle model, but has no secure
implementation.
"The Random Oracle Model, Revisited"
http://philby.ucsd.edu/1998/98-11.html
The question is "how flawed?"
The flaw pointed out by the above paper relies on being able to manipulate the
description of your oracle. Also, it's a contrived signature scheme which
includes as one of its substeps "output the secret key." So while there is
something wrong, maybe it's not serious.
More importantly, "will we ever need to care?"
That's still open.
> There are several things we want from a model of a cryptographic
> primitive:
> 1) The model should be simple, straightforward, and easy to apply.
> I'd have to work with the random oracle model for a while to
> see how well it does on this score, but at a first glance it
> seems to do pretty well on this score.
Yes, it's easy to apply. Maybe a bit TOO easy. In the kind of cryptography
which tries to provide provable security, a common technique for proving
security is "simulation." You show that an adversary who can break the
cryptosystem while interacting with a simulator which does not know the
private key would necessarily contradict some hardness assumption.
In such proofs, the simulator needs to provide "consistent-looking" answers to
the adversary for the adversary's calls to a hashing oracle. That is, the
adversary wants to evaluate H(x), and the simulator is allowed to decide what
value, exactly, H(x) will be.
The Random Oracle assumption is used to license the simulator outputting
**anything it wants** from the hashing oracle. The reasoning is that H() is a
randomly chosen function, so the adversary has no consistency conditions which
could lead it to reject any of its values as "inconsistent." So the simulator
can ouput something which the adversary then uses later in an essential way
to contradict the hardness assumption. The proof of security depends on the
simulator being allowed to choose these values however it wants.
This point is worth repeating: for these kinds of proofs, the RO assumption is
*not* used in the sense of some kind of "generalized collision
intractability." We do not first derive some relation which would have to hold
in order for the adversary to break the scheme, and *then* argue that because
H is a random oracle, such a relation cannot hold. Instead, we use the RO
assumption to allow the simulator to hand some information to the adversary
during the simulation.
I may be overstating the case, but the fact remains that the RO assumption is
used in a strong way in some proofs. Now, it *may* be possible to convert
every such proof into one which uses a RO in a "generalized collision
intractable" way. That is, a proof which first proves that a particular
relation would have to hold across some function H() to break the scheme, and
then argues that because H is a random oracle, the relation does not hold.
In particular, perhaps you could derive such relations always by a careful
analysis of the simulator's behavior in all these RO proofs. I haven't
investigated this.
Anyway, the fact is that as used, the RO model justifies proofs which at first
seem a little odd. So while it is easy to apply, it may be a bit "too
easy." That's still an open question!
In particular, it wasn't the focus of the Canetti-Goldreich-Halevi result,
which focused more on what happens when you're allowed to treat the
description of the oracle as something you can talk about.
So far as I know, the only other currently published papers near the subject
of RO definitions per se (instead of potential implementations) are
Hada and Tanaka
"A Relationship between One-Wayness and Correlation Intractability"
http://citeseer.nj.nec.com/hada99relationship.html
and more recently
Magic Functions (2000)
Cynthia Dwork, Moni Naor, Omer Reingold, Larry Stockmeyer
http://citeseer.nj.nec.com/dwork00magic.html
> 2) It should be possible to efficiently implement approximations
> to the model which are good enough that security proofs using
> the model are convincing.
> I can see no reason why a cryptographic hash function which
> attempts to model a random oracle should be significantly
> slower than a Merkle-Damgard hash function. For example,
The problem is that the current understanding of a "random oracle" is too
strong, and so a hash function which lived up to it entirely might look weird
indeed. It's not even clear to me that a deterministic function can do so. If
no deterministic function can "really" instantiate a random oracle as
currently understod, then this says bad things either about current practice
or about the model or both.
> consider a variant of the Merkle-Damgard design in which the
> compression function takes two additional bits of input--one
> indicating whether the block being compressed is the first
> block of the input, and another indicating whether the block
> being compressed is the last block of the input. This would
> defeat the attack you describe, and only increase the complexity
> of the hash function slightly.
Yes, it would defeat the attack described. But the resulting hash function
might still be far from being a random oracle. If all we care about is
defeating the attack, we should *say so* and then introduce a heuristic to
get rid of the attack. We should not then turn around and say that now
we have a real life random oracle.
There are two distinct issues here which we have to be careful about.
1) Assuming the model is OK, is a particular algorithm a "good"
real-world instantiation of the model? How can we build an algorithm
with a hope of being a good instantiation?
2) Is there something in the model which makes it difficult or
impossible for any "good" instantiations to exist?
The papers previously mentioned focused on 2). There's also some work on 1)
Perfectly One-Way Probabilistic Hash Functions
Ran Canetti, Daniele Micciancio, Omer Reingold
http://citeseer.nj.nec.com/canetti98perfectly.html
These define a nice notion of "perfectly one-way hash function." These are
actually promising as implementations for random oracles - for instance, it
seems that they may satisfy the "Hash Diffie Hellman Assumption" Abdalla,
Bellare, and Rogaway use in their new scheme DHAES.
Except the fact that they're probabilistic means that you *cannot* simply
assume that all parties will obtain the same value for H(x). In particular,
protocols which XOR outputs with the output of a hash function -- like OAEP
-- no longer work. This is a problem.
> 3) Algorithms which aproximate the model should be available "off
> the shelf." The random oracle model falls down here, but that
> could change over time.
Yes and no. How much of an approximation are you willing to take? SHA-1 or MD5
provide a passable approximation, except for the nasty property previously
noted. The word "approximate" has way too much wiggle room. :-\
>> 3. Merkle-Damgard hashes should not be used to instantiate random
>> oracles with variable length inputs that are not prefix-free.
> They shouldn't--but who wants to worry about rules like this? That
> is why I would like to see the cryptographic community develop hash
> functions that are not (known to be) vulnerable to any attacks.
No one, of course. The problem is in figuring out what you consider an
attack. The flaw in the MD family of hash functions is may not be a problem
for your particular situation. So you have to take a long view and ask about
what kinds of properties might lead to attacks.
Oh, and there's the nasty fact that we might not know about all the properties
which hash functions have, unless we prove that they don't have such
properties. :-(
The Random Oracle model can be considered as an attempt to move "beyond" the
question of which properties are important in which situations by proposing a
definition of security that is maximally strong. This is what Goldwasser and
Micali did for public-key encryption, and there it worked *fantastically*
well. For random oracles it has worked less well.
>> 4. The random oracle model is inappropriate for modelling symmetric
>> schemes, because the RO assumption trivially implies most
>> results about symmetric schemes that we would want to prove (i.e.
>> we are basically assuming the result).
> It's *good* if the correctness of a scheme is trivially self-evident;
> any time you deal with something that's nontivial you risk getting it
> wrong. So, assuming that we can in fact build hash algorithms that
> can be modelled as random oracles, we should do so.
The point here, I think, is that in the Random Oracle Model, you end up making
things trivial that - IF you're interested in the properties of a hash
function or a block cipher - really *aren't*. Like, what if I wanted to prove
SHA-1 secure, I could naively say
1) Let O be a random oracle. O is collision-free.
2) SHA-1 instantiates O, therefore SHA-1 is collision-free.
This is trivial and unsatisfactory. (maybe even "on crack.") The reason it's
unsatisfactory is that the RO model has covered up all of the issues which are
important for asessing whether SHA-1 really is any good or not.
What we need is what your point was, I think - we need to say something like
1) Let O be a random oracle. O is secure.
2) It means X Y and Z to be a "good" instantiation of O.
3) SHA-1 has X, Y, and Z.
4) Therefore SHA-1 is a good instantiation of O.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Sat, 20 Jan 2001 04:00:41 GMT
Greggy wrote:
*****************
> --
> 13th amendment to the US Constitution:
> If any citizen of the United States shall accept, claim, receive,
> or retain any title of nobility or honour, or shall, without the
> consent of Congress, accept and retain any present, pension, office,
> or emolument of any kind whatever, from any emperor, king, prince,
> or foreign power, such person shall cease to be a citizen of the
> United States, and shall be incapable of holding any office of
> trust or profit under them, or either of them.
>
> Sent via Deja.com
> http://www.deja.com/
=============================
Also you tell this to all American military people who
fought with nazis and then accepted honors and decorations from
Britain, France, Holland and Russia. They will probably agree
with you and will voluntarily renege their citizenship.
What I wanted to say is that this s--t of legislation would
perfectly befit some primitive cannibalistic tribe. However,
any country with even a rudimentary notion of civilization
should be deeply ashamed of it. Aren't you? Or maybe, you
first need to develop the very concept of shame?
BNK
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sat, 20 Jan 2001 04:05:59 GMT
zapzing wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote:
> > zapzing wrote:
> > >
> > > In article <[EMAIL PROTECTED]>,
> > > "buddy_holly" <[EMAIL PROTECTED]> wrote:
> > > > here are some good free PC operating systems:
> > > > (you can burn these ISO images with most cd-r software and a cd
> > > burner)
> > > >
> > > > Red Hat Linux 7.0:
> > > >
> ftp://ftp.redhat.com/pub/redhat/current/i386/iso/7.0-respin-disc1.iso
> > > >
> ftp://ftp.redhat.com/pub/redhat/current/i386/iso/7.0-respin-disc2.iso
> > > >
> > > > FreeBSD 4.2:
> > > >
> > >
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/4.2-install.i
> > > so
> > > >
> > >
> > > Most people. like me, won't want to deal
> > > with the installation hassles of Linux, so
> > > the danger remains that a national crisis
> > > could be made much worse by MS's Product
> > > Activation scheme.
> >
> > Linux is EASIER to install than windows.
> >
> > Boot up the install program...it installs ALL of your hardware drivers
> > in one pass...AND about 1,500 applications.
>
> Hmm.. which "flavor" of linux are
> you talking about? And on which
> machine?
>
> > all that with ONE reboot.
> >
> > Doing the equivalent on Windows would take you over a month.
>
> Except that most people never do it at all.
> It comes on the machine. Can't get any
> easier than that!
>
> --
> Void where prohibited by law.
>
> Sent via Deja.com
> http://www.deja.com/
Last Linux install I did was SuSE 6.4 and it was that easy. You do have
to know some stuff in advance, though. So it does pay to RTFM. Such
things as what time zone you live in and what keyboard mapping you would
like to have. Because I build my own systems, I keep around detail info
on my hard drives, modems, eathernet cards, sound cards, etc., just in
case.
SuSE went on just fine in about 45 minutes, most of which was spent
formating hard drives. Last NT install I did took all day with a reboot
about every 15 minutes.
--
Russ
<http://www.flash.net/~lyttlec>
Not powered by ActiveX
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Fri, 19 Jan 2001 20:03:21 -0800
lemaymd <[EMAIL PROTECTED]> wrote in message
news:94aqn0$qrs$[EMAIL PROTECTED]...
> To all interested:
> Bermuda Triangle 2001 is an extremely fast, easy-to-use and secure
> cryptography engine. It is based on a new, 32768-bit algorithm of the same
> name. Algorithm details can be found at my site as well as a software
> product that uses the algorithm, Bermuda Triangle 2001 Golden Edition. I
> also have a free cryptography engine that uses a similar (but incompatible)
> algorithm available for download. Visit the site at:
> http://www.bermudatriangle.f2s.com/
> These software packages are written entirely in 32-bit, win32 assembly
> language and I can encrypt or decrypt an 8.4MB file on my Pentium(R) 166 in
> 8 seconds. Please give me your feedback!
Be prepared, you're going to see some weird replies. Perhaps a few
rude ones. The problem is that your post is target rich for snake oil
de-bunkers regardless of any merit it might have.
Have you read the Snake Oil FAQ written by C Matt Curtin often
posted here? The 10 part Sci-crypt FAQ? Applied Cryptography?
It is inconceivable that you would read those and then compose your
post as you did.
Now comments. In assembler, 8.4 Megs per 8 seconds on a 166 Pentium
is slow, real slow.
That's like 150 clocks per byte where Twofish does ~18. There are
even faster algorithms.
32768 bit cryptography? Do you realize how unrealistic that is?
1024 bit cryptography (If you are talking symmetric) will never be broken
by any little green man that any offspring of yours might meet, no matter
how far into the future you speculate.
32768 is like saying it uses "Dylithium Crystals".
Hope you take this right.
Paul
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
** 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
******************************
