Cryptography-Digest Digest #588, Volume #13 Mon, 29 Jan 01 19:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: JUNIPER and BATON (Doug Stell)
Re: Why Microsoft's Product Activation Stinks (phil hunt)
Re: Why Microsoft's Product Activation Stinks (phil hunt)
first announcement for ECC 2001 (Alfred John Menezes)
Re: 3G crypto algorithms (Peter Gutmann)
Re: Primality Test ("Adam Smith")
Re: JUNIPER and BATON (Markku-Juhani Saarinen)
Re: How many bits of security can a password give? (Splaat23)
Re: On combining permutations and substitutions in encryption (Terry Ritter)
Re: Primality Test ("Matthew J. Ricciardi")
Re: Very short redundant serial number (Splaat23)
Re: What do you do with broken crypto hardware? (Peter Gutmann)
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) (Taneli
Huuskonen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Mon, 29 Jan 2001 22:25:09 GMT
On Sun, 28 Jan 2001 13:10:28 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>[...]
>Does that mean that OTP has a weakness? You can't double encipher with
>OTP and gain strength.
>
>IIUC, what Ritter mean by "multiple ciphering with itself alone will not
>provide additional strength," was that if encipher the message with DT,
>and without using a new key/altering the state, encipher again, the
>cipher will not be stronger.
Actually, my comments came in the context of DES groupiness: As it
stands, a single Dynamic Transposition already produces *any possible
permutation*. So if we do Dynamic Transposition again, we *still*
have *any possible permutation*. Nothing changed, so there was no
strength increase *in the Triple-DES sense* of a keyspace increase.
I was not addressing whether or not multiple ciphering with Dynamic
Transposition would hide the individual key to each ciphering level,
which may well be the case, and, in that sense, might indeed add
strength.
>This is analogous to the following:
>
>Here's cipher 1, it uses a keystream generator:
> pt, ct = plaintext, ciphertext
> ks = The first |pt| words of keystream
> ct = pt XOR ks
>
>Here's cipher 2, it also uses a keystream generator:
> pt, ct = plaintext, ciphertext
> ks1 = The first |pt| words of keystream
> ks2 = The next |pt| words of keystream
> ct = pt XOR ks1 XOR ks2
>
>Is cipher 2 stronger than cipher 1? Ritter is saying, that with DT as
>the combiner, cipher 2 is not stronger than cipher 1... no matter how
>many times one adds part of the keystream, the amount of work needed to
>attack is equal to the amount of work needed to brute force the key.
>
>Of course, this doesn't mean you can't make it stronger... it just means
>that the only way to make it stronger is to lengthen the key.
Yes, but I think this part of strength is really overplayed: Once we
have a "large enough" key (large enough to prevent a brute-force
attack on the keys), we don't need more of that type of strength, but
must instead address other types of attack.
Having a larger key is not *wrong* per se, just not helpful with
respect to brute-force attacks on keys. There can be various clarity
or implementation reasons for having large keys.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: JUNIPER and BATON
Date: Mon, 29 Jan 2001 22:41:02 GMT
On Mon, 29 Jan 2001 06:39:53 +0000 (UTC), Markku-Juhani Saarinen
<[EMAIL PROTECTED]> wrote:
> Does anyone have any details on the usage and origin of the
> JUNIPER and BATON encryption algorithms ?
>
> These just popped up (alongside CAST, KEA etc) while I was
> examining a crypto library from a vendor traditionally associated
> with the governments of the english-speaking world.
Your last line above should be a clue that, as use to be the case with
KEA,
a) some people have details, but will never admit it, and
b) the cover name is all you will ever get for details.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Mon, 29 Jan 2001 18:19:59 +0000
On Sun, 28 Jan 2001 23:51:06 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>, Anthony Stephen Szopa
>> <[EMAIL PROTECTED]> wrote:
>>
>> > So why did they not hire software engineers and pay them to develope
>> > a first rate OS to compete with MS's?
>> >
>> The high ground in system development is taken, and it's not with MS.
>>
>> > I say the reason was fear. And look where it got them. As it
>> > turned out, they really had nothing to lose but they didn't even
>> > try.
>>
>> I'd say that things are not settled yet.
>
>I like your sense of humor.
>
>Bill Gates is worth nearly a hundred billion dollars and you can say
>things are not settled yet.
He's not worth that much -- MS's share price is 50% down on its
Dec 1999 high.
Also consider that MS's market share in the PC market is stagnant,
and on servers they are actually losing market share, if the netcraft
figures are anything to go by. Also, PC sales are failing to grow
as rapidly as they did, so it is clear that MS's revenue cannot increase
in the future as much as it has in the past.
"Information appliances" -- set top boxes, personal organisers, mobile
phones and the like -- are growing much faster than PCs, and in this
market MS doesn't dominate: the Palm OS and EPOC are doing well for
perosnal organisers, and Linux is popular too, partly because MS's
license fee is too much when you are selling a cheap device.
Furthermore, the failure to win the Internet server market means
that MS cannot use their usual tactic of vendor lock-in to control
the information appliance market. Their other main tactic,
predatory pricing to starve their competitors of revenue, can't
work when the competition is open source.
Sun, IBM, Oracle, SGI, HP, etc, are all investing money into open
source and/or Linux. MS may think they are all ganging up against
them: they're right, because the other companies have rrealised
that in a MS-dominated world, they will have little chance for
revenue or profit, apart from the crumbs from Billy's table. This
is esentially the reason why Sun are giving away Open Office, for
example. MS have only got themselves to blame with their dubious
(and often illegal) tactics.
--
*****[ Phil Hunt ***** [EMAIL PROTECTED] ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Mon, 29 Jan 2001 16:02:36 +0000
On Mon, 29 Jan 2001 00:10:22 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>If the Industry sticks together on this people will cooperate. I
>would just like to see software prices come down as a result.
Not possible. Linux is free. StarOffice is free. Apache is free.
Leafnode is free. PHP is free. Python is free. GCC is free. The
only way these prices will go down is if people pay me to use their
software, which ain't gonna happen.
Oh, you meant *proprietary* software? Sorry, I don't use that. I've
been messed around once too often by upgrade treadmills, deliberately
incompatible file formats, and deliberately broken software (which
includes anti-"piracy"(1) "features").
>Even the stockholders of these companies want to have this anti-
>piracy feature implemented.
>
>Obviously most pirates and jealous and fearful people don't because
>it will give that much more control to BG and the Industry.
On the contrary, the most hassle BillyShit make their products to use,
the more people will move over to the Linux alternative.
>But I believe it will happen nevertheless.
You may well be right.
(1) I note you use the word "pirates" to describe people who make
unauthorised copies of software. Is that because (i) you think it
is morally equivalent to attacking a ship on the high seas, raping
and murdering its crew, (ii) because you have bought into the
proprietary software industry's propaganda, or (iii) some other
reason?
--
*****[ Phil Hunt ***** [EMAIL PROTECTED] ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: first announcement for ECC 2001
Date: 29 Jan 2001 22:32:12 GMT
==============================================================================
THE 5TH WORKSHOP ON ELLIPTIC CURVE CRYPTOGRAPHY (ECC 2001)
University of Waterloo, Waterloo, Canada
September 17, 18 & 19 2001
First Announcement January 29, 2001
ECC 2001 is the fifth in a series of annual workshops dedicated to the
study of elliptic curve cryptography and related areas. The main themes
of ECC 2001 will be:
- The discrete logarithm and elliptic curve discrete logarithm problems.
- Provably secure discrete log-based cryptographic protocols for
encryption, signatures and key agreement.
- Efficient software and hardware implementation of elliptic curve
cryptosystems.
- Deployment of elliptic curve cryptography.
It is hoped that the meeting will encourage and stimulate further
research on the security and implementation of elliptic curve
cryptosystems and related areas, and encourage collaboration between
mathematicians, computer scientists and engineers in the academic,
industry and government sectors.
There will be approximately 15 invited lectures (and no contributed
talks), with the remaining time used for informal discussions. There
will be both survey lectures as well as lectures on latest research
developments.
SPONSORS:
Certicom Corp.
Communications and Information Technology Ontario
MasterCard International
MITACS
Mondex International Limited
University of Waterloo
ORGANIZERS:
Alfred Menezes (Certicom Corp.)
Edlyn Teske (University of Waterloo)
Scott Vanstone (University of Waterloo)
CONFIRMED SPEAKERS:
Dan Bernstein (University of Illinois Chicago, USA)
Dan Bleichenbacher (Lucent Technologies, USA)
Dan Boneh (Stanford University, USA)
Dan Brown (Certicom Corp., Canada)
Gerhard Frey (University of Essen, Germany)
Pierrick Gaudry (Ecole Polytechnique, France)
Darrel Hankerson (Auburn University, USA)
Alfred Menezes (Certicom Corp., Canada)
Tatsuaki Okamoto (NTT, Japan)
Jean Marc Robert (Gemplus, Canada)
Alice Silverberg (Ohio State University, USA)
Brian Snow (National Security Agency, USA)
Jerome Solinas (National Security Agency, USA)
Annegret Weng (University of Essen, Germany)
LOCAL ARRANGEMENTS:
The city of Waterloo is about 50-minute drive from Toronto
international airport. The second announcement will be made on
March 16, and will include registration and local (i.e., hotel &
transportation) information. If you did not receive this
announcement by email and would like to be added to the mailing
list for the second announcement, please send email to
[EMAIL PROTECTED] The announcements are also available
from the web site www.cacr.math.uwaterloo.ca
==============================================================================
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: 3G crypto algorithms
Date: Mon, 29 Jan 2001 23:19:04 -0000
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>Yes, near Bad Aibling there are a number of spherical domes
>that contain the equipments for interception. Sometime back
>there were some reports about the station in the newspapers
>but I can't find the references for you now. Because of the
>rumours (or not, I don't know, nor apparently any other
>outsiders) of the activities of commercial espionage, the
>station accepted to be visited by a high rank German government
>officer, who was assured by the persons there that there never
>had been such activities. I don't know much more than the above.
I was there a few months ago (outside, not inside :-) and took a lot of photos
of the place, once I get them developed and can get them to a scanner I'll put
them online (this will probably take awhile). It seems to have expanded
considerably since the few photos which exist were taken (and/or the photos are
pretty old) because there are quite a number of radomes there now.
Peter.
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Re: Primality Test
Date: Mon, 29 Jan 2001 23:29:15 GMT
I'm running VB, that could be the problem. The author of my bignum package
cites the following for the primality test:
'Schneier, Applied Cryptography, p.260
'Robbins, Beginning Number Theory, p.262
so I assume he knows what he's doing. It probably has something to do with
VB's high-level calls...
At any rate, this is my final plea. I considered posting this to a new
thread, but that would be my fourth on this RSA stuff...but it comes down to
this: I need ONE RSA key. If I plugged away at this thing, I would only
generate one key with it anyway. Could someone who has the facilities to
generate RSA keys do so to make a 1024 bit key and send it to me? (Note: in
the form of the numbers n, e, and d (p & q optional), not like one generated
by PGP or anything)
Thanks!
Adam Smith
"Splaat23" <[EMAIL PROTECTED]> wrote in message
news:9522t5$bvm$[EMAIL PROTECTED]...
> Umm, written in native Python (an interpreted language), a single
> Miller-Rabin round on a 512 bit condidate takes .05 seconds. You've
> done something wrong with the algorithm, or your big number library is
> REALLY slow.
>
> One of the best ways to generate primes is to pick a random number of
> the correct range, fix the most and least significant bit to 1, and
> increment by 2 until you get a prime. Each candidate can be tested
> first with trial division of the firxt X primes to screen obvious
> composites, then with a couple of rounds of Miller-Rabin.
>
> Your posts here are not getting annoying, but most of the answers _are_
> available from other, better sources, such as books. I would recommend
> getting the Handbook of Applied Cryptography. It's even available for
> free on the Internet. Read it before asking a question and you'll be
> guaranteed that the answer is not _completely_ obvious.
>
> - Andrew
>
> In article <8I%c6.3988$[EMAIL PROTECTED]>,
> "Adam Smith" <[EMAIL PROTECTED]> wrote:
> > Once again, this is for generating RSA keys...if all of my posts here
> are
> > getting annoying or are out-of-place, please say something....
> >
> > I'm not having trouble generating random numbers with 150-200 digits,
> my
> > problem comes in testing to see if they're random...I'm using an
> > implementation of the Rabin-Miller primality test with even only one
> round
> > (if true then probability that the number is composite is < .25^
> (number of
> > rounds)), but it's taking an extremely long time to test...I had to
> force
> > close the app before it even tested one number (it's using a Pentium
> III 500
> > MHz chip)...
> >
> > Any tips on generating 512 bit prime numbers?
> >
> > Once again, thanks in advance!
> > Adam Smith
> >
> >
>
>
> Sent via Deja.com
> http://www.deja.com/
>
------------------------------
From: Markku-Juhani Saarinen <[EMAIL PROTECTED]>
Subject: Re: JUNIPER and BATON
Date: Mon, 29 Jan 2001 23:21:47 +0000 (UTC)
Doug Stell <[EMAIL PROTECTED]> wrote:
: On Mon, 29 Jan 2001 06:39:53 +0000 (UTC), Markku-Juhani Saarinen
: <[EMAIL PROTECTED]> wrote:
:> Does anyone have any details on the usage and origin of the
:> JUNIPER and BATON encryption algorithms ?
:>
:> These just popped up (alongside CAST, KEA etc) while I was
:> examining a crypto library from a vendor traditionally associated
:> with the governments of the english-speaking world.
: Your last line above should be a clue that, as use to be the case with
: KEA,
: a) some people have details, but will never admit it, and
: b) the cover name is all you will ever get for details.
I see. Thanks.
- mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Mon, 29 Jan 2001 23:23:50 GMT
My memory may be failing me, but I recall Shannon's numbers are wrt.
large texts (i.e. books), where patterns have more of a chance to be
exposed. With passwords, I bet there's around 3-4 bits per byte,
because they are short and don't have spaces (generally). Shannon's
research, however, is definately applicable to passphrases, because
they are "phrases". However, all of this is simplistic logic, so use
with caution.
- Andrew
In article <OhdAxOjiAHA.338@cpmsnbbsa09>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>
> "George Weinberg" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > On Wed, 24 Jan 2001 11:50:11 -0800, "Joseph Ashwood"
<[EMAIL PROTECTED]>
> > >Depends on the password. If you let the user choose an English
word, it
> is
> > >rather predictably 1 bit of entropy per character. If you require
that
> there
> > >be at least one capital, they will almost certainly capitalize the
first
> > >letter, so maybe .25 bits of entropy added. Adding a number on the
end
> adds
> > >an average of log2(10) although it will be biased towards 1. So
your
> normal
> > >passwords would have anywhere from 6 to ~12 bits of entropy.
> >
> > This is way pessimistic. 12 bits of entropy implies you could get
it
> > with a dictionary attack with only 4000 guesses. six bits
> > means you would only need 64 guesses!
>
> Actually I need simply refer back to the proofs by, I believe it was,
> Shanon. Which proved rather conclusively that English has between 1
and 1.5
> bits of entropy per character. Even assuming 2 bits per character
(which
> would be a much better password than is typical) that is still only
16 bits
> or so. These are not wild guesses, these are based on mathematical
proofs.
> There's some hedgeway here because people tend to choose more obscure
words
> for passwords, and those words have a higher average entropy. The
thing is
> if they use English you're not going to get much entropy.
> Joe
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On combining permutations and substitutions in encryption
Date: Mon, 29 Jan 2001 23:29:56 GMT
On Mon, 29 Jan 2001 11:59:31 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>Since the PRNG output is not 'directly' used, as would have
>been the case of using it to xor the plaintext, the values
>of its output are never directly exposed to the opponent
>in the combination depicted above, even if he acquires
>both plaintext and ciphertext. This 'indirectness' of
>employment of the PRNG output largely shields its
>predictability from being exploited. On the other hand, we
>evidently cannot in practice have any guarantee of 'absolute'
>infeasibility of analysis resulting alone from the said
>'indirectness',
It is easy to have a prejudice that a cipher cannot be provably
secure. The most difficult part of this might be the implicit
understanding of "from any possible attack." But most ciphers have a
range of currently-known and most-likely attacks, each of which might
be addressed and proven *impractical*, if not absolutely impossible.
The obvious attack is on the RNG keyspace, the internal state. But we
can easily make ciphers with hundreds of thousands of bits of internal
state, which is far more than "large enough." When we do, we at least
have the opportunity of proving that any attack on the keyspace must
be impractical. There is nothing unreasonable about this.
To gain information about the contents of internal state, we seemingly
must know the input, the output, or both. And if we have shown that
knowing the key -- the RNG input -- is impractical, any attack
seemingly must be on the sequence -- the RNG output -- and must be
made "by analysis," through the ciphertext channel.
We assume that the opponent has known plaintext, so any additive
combiner like XOR will immediately expose the ciphering sequence,
which then could be used to attack the RNG. But if we use a stronger
combiner -- for example, a keyed Latin square -- the ciphering
sequence is not so exposed. If we study this, we can show that some
RNG information is not hidden, but the most obvious information is
hidden. That is a clear improvement not anticipated in the
literature, so there is nothing to tell us how far that can go.
Since some RNG information is hidden by the advanced combiner, the
issue of whether *all* relevant information can be hidden is more than
some vain hope; it is a reasonable question. A positive example would
indeed be "absolutely" unbreakable for attacks from the ciphertext
channel, but not necessarily unbreakable for unlimited computation.
This is not weird science.
>[...]
>That is, the predictability of the
>PRNG used cannot be caused (by whatever devices) in practice
>to magically disappear 'absolutely and entirely' in our
>results of encryption, though very much reduced.
An RNG is only predictable when we know enough about it. While we
cannot expect to create unpredictability by computation, we might well
hope to achieve the inability to exploit the predictability we know is
there.
I am unaware of any proofs in cryptography which would prevent one
from achieving a complete information hiding in a combiner or a
sequence or array of combiners.
I am unaware of any proofs in cryptography which would prevent one
from achieving a known extent of information hiding, so that the
combiner or RNG could be re-keyed before sufficient information was
available for solution.
Claiming that an RNG cipher simply cannot ultimately be secure as a
fact is just unscientific.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Matthew J. Ricciardi" <[EMAIL PROTECTED]>
Subject: Re: Primality Test
Date: Mon, 29 Jan 2001 18:28:12 -0500
As an exercise for a discrete math course, I was asked to write a program to
test numbers for primness. I also chose the use the Rabin-Miller method as
described in Schneier's Applied Cryptography and am experiencing similarly
slow performance.
The vast majority of the run time is spent calculating an initial value for
z such that z = (a ^ m) mod p.
The source code for the computation currently reads as follows:
z = 1;
for(int x = 1; x <= m; x++)
{
z *= a;
z = (z % p);
}
As was suggested by Timmermans, I am performing the modular reduction after
each multiplication to avoid inordinately large numbers. However, the
algorithm still involves performing m multiplications.
Can any further improvement be easily made to improve performance?
Thanks,
Matt Ricciardi
[EMAIL PROTECTED]
"Adam Smith" <[EMAIL PROTECTED]> wrote in message
news:8I%c6.3988$[EMAIL PROTECTED]...
Once again, this is for generating RSA keys...if all of my posts here are
getting annoying or are out-of-place, please say something....
I'm not having trouble generating random numbers with 150-200 digits, my
problem comes in testing to see if they're random...I'm using an
implementation of the Rabin-Miller primality test with even only one round
(if true then probability that the number is composite is < .25^(number of
rounds)), but it's taking an extremely long time to test...I had to force
close the app before it even tested one number (it's using a Pentium III 500
MHz chip)...
Any tips on generating 512 bit prime numbers?
Once again, thanks in advance!
Adam Smith
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Very short redundant serial number
Date: Mon, 29 Jan 2001 23:31:17 GMT
If you're not worried about people generating fake numbers, then just
about any equation F(n, i), like n * i, where n is the digit at index
i, combined for each digit, mod 100, should suffice for error checking.
There are many more complicated ways to do it, some cryptographically
strong, but this is easiest and, if I gauge your desires correctly, the
best.
- Andrew
In article <954n62$hbo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I know this is borderline faq, but hopefully one of you can help me
> out. I need to create a very short list of serial numbers, only 100.
> Users will be entering in the number manually on a keypad. I would
> like to build in some redundancy so they have a lower chance of
> accidently entering the wrong number. Say 2 more digits (4 total).
>
> I've considered a couple of schemes based on previous posts on the
> topic, but most of these seem to be geared towards much larger
numbers,
> and much lower relative redundancy. Can any of you suggest a simple
> scheme that will catch the common mistakes like swapped numbers and
> digits off by one?
>
> Ken
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: What do you do with broken crypto hardware?
Date: Tue, 30 Jan 2001 00:03:27 -0000
Paul Rubin <[EMAIL PROTECTED]> writes:
>The keys in the modules I'm using are internally stored in flash memory,
>so removing power won't erase them. Erasure is a powered operation that
>involves writing zeros to the flash, like erasing sectors on a disk.
During the erase process no data is actually written (well, usually, some
EEPROM/flash architectures may program all cells before erasing them to avoid
problems with overerasure), the erase process just transitions all cells into
the erased state (or at least something which is close enough to the erased
state that the sense amplifiers can't tell the difference), which may be all
zeroes or all ones depending on the cell type.
In addition, erasing the cell doesn't necessarily mean the data is really gone.
If you're really concerned I'd physically destroy the memory, and if you're
really paranoid and worried about big-budget attackers, the crypto device it
fed as well.
Peter.
------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks)
Date: 30 Jan 2001 01:53:50 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In <[EMAIL PROTECTED]> Anthony Stephen Szopa
<[EMAIL PROTECTED]> writes:
>Taneli Huuskonen wrote:
[...]
>>
>> 2. Assume the cryptanalyst can guess _part_ of the key - the part
>> that describes how the raw pseudorandom bytes are shuffled after they've
>> been generated. This could well happen, if the user had originally
[...]
>The rules state that the cracker has enough plain text / cipher text
>such that to have any more won't make any difference.
>You have not or cannot support or justify your 2. assumption.
Are you claiming it can never happen in practice?
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOnYCfl+t0CYLfLaVEQKQ4wCeMG2ol561o8estRl5P7Kjz88rF+kAoPhv
ArdHeFUrSX805gcqmIUo0M4v
=25ib
=====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/
------------------------------
** 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
******************************
