Cryptography-Digest Digest #115, Volume #12 Tue, 27 Jun 00 11:13:01 EDT
Contents:
Re: Key agreement in GSM phones (Gerard Tel)
Re: Idea or 3DES (Mark Wooding)
Re: TEA-wmlscript question (dexMilano)
silly question about TEA (dexMilano)
Re: TEA question (dexMilano)
Re: SV: DES Weakness ? (Pascal JUNOD)
[Correction] (Pascal JUNOD)
Dixon's random square algorithm ("íÅÄ×ÅÄÅ× íÉÈÁÉÌ")
Dixon's random square algorithm ("íÅÄ×ÅÄÅ× íÉÈÁÉÌ")
Re: TEA question ([EMAIL PROTECTED])
Re: How Uncertain? (Tim Tyler)
Re: How Uncertain? (Future Beacon)
Re: TEA question (dexMilano)
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (Tim Tyler)
Re: How Uncertain? (Tim Tyler)
Re: Compression & Encryption in FISHYLAND (Johnny Bravo)
Re: Quantum computing (Tim Tyler)
Dynamical Cryptography algorithm ([EMAIL PROTECTED])
Re: TEA question (Mark Wooding)
Re: Remark on practical predictability of sequences ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Gerard Tel <[EMAIL PROTECTED]>
Subject: Re: Key agreement in GSM phones
Date: Tue, 27 Jun 2000 12:11:08 +0200
David,
thanks for your clear description.
I understand that the unique number Ki in the SIM circulates through
the infrastructure so it is a `shared secret' between the handset and
the base station. Now my next questions are:
- Is it possible for an intruder to tap the Ki information from
the network? (Intruder = criminal, police, or government)
- I learned that the A8 computation differs from provider to provider.
Now if you use your phone in another provider's network where
the phone and base do not share the A8, what happens?
"David A. Wagner" wrote:
> Actually, Ki usually lives not on the
> base station but in the infrastructure, and the infrastructure computes
> Kc and SRES from Ki and the challenge on behalf of the base station.
--
Gerard Tel
http://www.cs.uu.nl/~gerard/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Idea or 3DES
Date: 27 Jun 2000 10:50:34 GMT
David Blackman <[EMAIL PROTECTED]> wrote:
> Can you use a conditional move instead? Available on Pentium-2 and
> also on ARM and some other RISC chips :-) Not available on older X86
> chips :-(
I don't think I could. The problem was that I had to notice zero-valued
inputs, do something with them, and then branch around the main code
which did the multiplication and fiddling with carries. By the time I'd
finished, I was convinved that it couldn't really be improved beyond
what I was already doing.
> Conditional moves are usually as fast as other register ops and much
> faster than a conditional branch.
Indeed. But the logic is too complicated to really take advantage.
> It's still not quite as quick as multiply shift and xor, which is
> nearly as nice, and probably what Mark would rather do.
<grin> Actually, I'm not particularly fond of multiplication as a
cryptographic primitive in general: there are usually better methods of
doing the same thing. For example, ciphers based on table lookup, such
as Blowfish and CAST, seem to be better suited to software
implementation. There are environments, for example DSPs, where the
conditions point firmly towards integer multiplication as a useful
operation.
It's probably worth noting at this point that Storin (my own design,
based around matrix multiplication over the commutative ring of the
integers mod 2^{24}) has rather poor performance on general-purpose
computers compared even to ciphers like IDEA, and certainly the fast
ones like Blowfish, Square and RC5. However, DSPs aren't good at the
same things which general-purpose compures are -- they don't have fast
random-access memory for table lookup, nor good rotation, nor are they
good at conditional logic, and many don't provide 32-bit words.
The relative `goodness' of various simple operations varies tremendously
according to your target environment. Bringing my waffling back on
track, I'm not sure, however, that IDEA fits any environment
particularly well: there's always something which works better.
-- [mdw]
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: TEA-wmlscript question
Date: Tue, 27 Jun 2000 11:39:21 GMT
Thanks for your complete explanation.
I think i'ts clear the meaning of Phi number
Do You mean that for crypto algoritms I don't need a particular number
but i can choose the one I prefer (for example 1234567)?
dex
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> dexMilano wrote:
> > So I can say that
> > \phi = a/b where a/b = b/(a+b)
> > and a, b and the their ratio are integer.
> > ???
>
> "???" is right -- that's incorrect. Phi is an irrational number.
>
> +----+-------+
> | | |
> | | | phi
> | | |
> +----+-------+
> 1 phi
>
> The ratio phi:(1+phi) is equal to the ratio 1:phi; that's where
> the name "the golden mean" originated. Simple high-school algebra
> then yields: phi^2 - phi - 1 = 0, which can be solved in various
> ways, e.g. the "quadratic formula": phi = 1/2 + sqrt(1/4 + 1) =
> (1 + sqrt(5))/2 which is approximately 1.618. phi's reciprocal is
> exactly one less than phi (exercise: prove!), approximately 0.618.
>
> > SO I think there are some tables anywhere.
>
> There would not be "tables" of a single number. I am sure
> that one can find phi's decimal expansion to a few dozen digits
> in some table of common constants, and certainly the first
> several digits of the decimal expansion of the square root of 5
> may be found in some table.
>
> > Why the number Golden number is so great?
>
> It's not so great. However, the Pythagoreans believed that it
> was the most aesthetic ratio for the sides of a rectangle, and
> that was used that in much Greek art (such as the Parthenon).
>
> In the current context, phi is a common irrational number whose
> decimal or binary expansion can be readily computed, and there
> is no obvious reason to expect a statistical bias in the digits
> of the expansion. I personally would prefer e or pi, which are
> also transcendental and thus less likely to have a simple
> pattern in their digits. (All these numbers *do* exhibit a
> particular pattern, in that their digits are easily computed.
> Thus they are no good at all as *secret keys*.)
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: silly question about TEA
Date: Tue, 27 Jun 2000 11:43:33 GMT
I've tested the java classes of TEA algorithm but it doesn't work.
I mean that tha initial pattern of bit is not the same as after
crypt/decrypt.
I know it's weird but I cannot find the error in the source.
Is there someone tried it successfully?
dex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: TEA question
Date: Tue, 27 Jun 2000 11:45:50 GMT
Thanks Adam.
But even if it's not TEA, it should work as cipher/decipher. doesn't it?
dex
In article <1DN55.383$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
>
> You don't have to use the golden number. When people choose a
constant to
> put into a cipher, they usually choose a well known number, such as
e, pi,
> or in this case the golden number. RC5 uses phi and e. Blowfish
uses pi.
> And I believe Serpent uses the golden number also. This is usually
done to
> show that the constant was not specifically chosen to create a
backdoor in
> the cipher. If you use a number other than the golden number in TEA,
it is
> no longer TEA, so keep that in mind if you choose to use some other
number.
>
> - Adam
>
> "dexMilano" <[EMAIL PROTECTED]> wrote in message
> news:8j8154$ifm$[EMAIL PROTECTED]...
> > Why we have to use the golden number ...
> > Why cannot we use 1569234 for example?
> >
> > thx
> >
> > dex
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 27 Jun 2000 14:00:11 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: SV: DES Weakness ?
> A fast pc that can do more than 1^6 des computations per second!
> Then that single pc should recover the key in less than 101 days ?
A Pentium III 666MHz is able to encrypt up to 2.8 millions of 64-bits
blocks in
one second when doing linear cryptanalysis.
Please check http://www.lasecwww.epfl.ch the next weeks for more
information.
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de Sécurité et de Cryptographie (LASEC) *
* ++ 41 (0) 21 693 7617, INR 313, EPFL, CH-1015 Lausanne *
* Route d'Yverdon 25, CH-1028 Préverenges, Switzerland *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Tue, 27 Jun 2000 14:02:30 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Subject: [Correction]
> Please check http://www.lasecwww.epfl.ch the next weeks for more
> information.
The right URL is http://lasecwww.epfl.ch
Sorry !
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de Sécurité et de Cryptographie (LASEC) *
* ++ 41 (0) 21 693 7617, INR 313, EPFL, CH-1015 Lausanne *
* Route d'Yverdon 25, CH-1028 Préverenges, Switzerland *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: "íÅÄ×ÅÄÅ× íÉÈÁÉÌ" <[EMAIL PROTECTED]>
Subject: Dixon's random square algorithm
Date: Tue, 27 Jun 2000 15:29:48 +0400
Hi!
The Dixon's factoring randomized algorithm has running time L(n)^sqrt(2),
where L(n) = e^(sqrt(logn*loglogn))
Can anybody tell me, how this time is calculated (or, where can I find an
article in which this calculation is made)
Michael.
------------------------------
From: "íÅÄ×ÅÄÅ× íÉÈÁÉÌ" <[EMAIL PROTECTED]>
Subject: Dixon's random square algorithm
Date: Tue, 27 Jun 2000 15:31:53 +0400
Hi!
The Dixon's factoring randomized algorithm has running time L(n)^sqrt(2),
where L(n) = e^(sqrt(logn*loglogn))
Can anybody tell me, how this time is calculated (or, where can I find an
article in which this calculation is made)
Michael.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TEA question
Date: Tue, 27 Jun 2000 12:26:33 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
dexMilano wrote:
> Thanks Adam.
> But even if it's not TEA, it should work as cipher/decipher. doesn't it?
> dex
yes..
but if you choose different number it anyway should be 32 bit number
so you cant use 1569234 - its too small - only 21 bit (1569234 == 0x17f1d2 ==
101111111000110110010 )
> In article <1DN55.383$[EMAIL PROTECTED]>,
> "Adam Durana" <[EMAIL PROTECTED]> wrote:
> >
> > You don't have to use the golden number. When people choose a constant to
> > put into a cipher, they usually choose a well known number, such as e, pi,
> > or in this case the golden number. RC5 uses phi and e. Blowfish uses pi.
> > And I believe Serpent uses the golden number also. This is usually done to
> > show that the constant was not specifically chosen to create a backdoor in
> > the cipher. If you use a number other than the golden number in TEA, it is
> > no longer TEA, so keep that in mind if you choose to use some other number.
> > - Adam
> > "dexMilano" <[EMAIL PROTECTED]> wrote in message
> > news:8j8154$ifm$[EMAIL PROTECTED]...
> > > Why we have to use the golden number ...
> > > Why cannot we use 1569234 for example?
> > > dex
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOViBMTBaTVEuJQxkEQJSMgCglYTSmDQLNVgpEhgqSvgThKj0UkAAnRNP
krpfJUmwM8GQ6mya6i1rV3wQ
=BRju
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 12:43:34 GMT
Future Beacon <[EMAIL PROTECTED]> wrote:
: Files A and B are composed of the least significant two bits of
: bytes found in news group messages (excluding headers, carriage
: returns, line feeds, and spaces). A and B contain one megabyte
: each of this data. In each case, these bits are strung together,
: four pairs per byte. At least three quarters of the original data
: available in the news group messages is not used.
: Then, file B is divided into two files (BP and BQ) this way: If the
: first bit in A is a 0, then the first bit in B becomes the first bit
: in BP. If the first bit in A is a 1, the first bit in B becomes the
: first bit in BQ. In this way, each next bit in A determines whether
: the next bit in B becomes the next bit in BP or BQ. When the bits
: of A and B are exhausted, BQ is appended to BP and the resultant
: file is called RAND.
[is this file likely to be random?]
Not really. About 1/4 of the values of the bits in B wind up verbatim in
RAND - assuming the 1/4 which is used (which you don't specify how you
choose) is decided genuinely at random.
Consequently any biases in the bits in B wind up as (slightly reduced)
biases in the output.
Since the bits in B come from the low bits of usenet messages - which
are /not/ likely to be unbiased (despite the omission of spaces) - the
resulting RAND file is likely to exhbit biases as well.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Date: Tue, 27 Jun 2000 09:29:02 -0400
On Tue, 27 Jun 2000, Tim Tyler wrote:
> In two newsgroups Future Beacon <[EMAIL PROTECTED]> wrote:
>
> : Files A and B are composed of the least significant two bits of
> : bytes found in news group messages (excluding headers, carriage
> : returns, line feeds, and spaces). A and B contain one megabyte
> : each of this data. In each case, these bits are strung together,
> : four pairs per byte. At least three quarters of the original data
> : available in the news group messages is not used.
>
> : Then, file B is divided into two files (BP and BQ) this way: If the
> : first bit in A is a 0, then the first bit in B becomes the first bit
> : in BP. If the first bit in A is a 1, the first bit in B becomes the
> : first bit in BQ. In this way, each next bit in A determines whether
> : the next bit in B becomes the next bit in BP or BQ. When the bits
> : of A and B are exhausted, BQ is appended to BP and the resultant
> : file is called RAND.
>
> : Two people wishing to send and receive encrypted messages use the
> : one-time-pad method but instead of using a random number generator
> : to create their shared random numbers, they use the file called
> : RAND.
>
> [is this file likely to be random?]
>
> Not really.
I'm sorry, but I did not ask this question. I know very well that
the file is not random. I asked how random.
Is there an on-line service that will statistically evaluate data?
Thank you for your help.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: TEA question
Date: Tue, 27 Jun 2000 13:59:46 GMT
Let's make the point.
I don't have unsigned so I have an upper limit of f7777777 (absolute
value).
I want to make 32 cicle so the initial value of delta should be int
(max/32) and it is 3ffffff (11111111111111111111111111 that has 26
bits); too small.
The smallest integer of 32 bits is 10000000000000... that is 80000000
i.e 2147483648. but this number exceed the limits.
Do yuo mean that I can't use this algorithm?
dex
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> dexMilano wrote:
> > Thanks Adam.
> > But even if it's not TEA, it should work as cipher/decipher.
doesn't it?
> > dex
>
> yes..
> but if you choose different number it anyway should be 32 bit number
> so you cant use 1569234 - its too small - only 21 bit (1569234 ==
0x17f1d2 == 101111111000110110010 )
>
> > In article <1DN55.383$[EMAIL PROTECTED]>,
> > "Adam Durana" <[EMAIL PROTECTED]> wrote:
> > >
> > > You don't have to use the golden number. When people choose a
constant to
> > > put into a cipher, they usually choose a well known number, such
as e, pi,
> > > or in this case the golden number. RC5 uses phi and e. Blowfish
uses pi.
> > > And I believe Serpent uses the golden number also. This is
usually done to
> > > show that the constant was not specifically chosen to create a
backdoor in
> > > the cipher. If you use a number other than the golden number in
TEA, it is
> > > no longer TEA, so keep that in mind if you choose to use some
other number.
> > > - Adam
>
> > > "dexMilano" <[EMAIL PROTECTED]> wrote in message
> > > news:8j8154$ifm$[EMAIL PROTECTED]...
> > > > Why we have to use the golden number ...
> > > > Why cannot we use 1569234 for example?
> > > > dex
>
> == <EOF> ==
> Disastry http://i.am/disastry/
> http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
> http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for
PGP
> remove .NOSPAM.NET for email reply
> -----BEGIN PGP SIGNATURE-----
> Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
>
> iQA/AwUBOViBMTBaTVEuJQxkEQJSMgCglYTSmDQLNVgpEhgqSvgThKj0UkAAnRNP
> krpfJUmwM8GQ6mya6i1rV3wQ
> =BRju
> -----END PGP SIGNATURE-----
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 13:57:42 GMT
zapzing <[EMAIL PROTECTED]> wrote:
: I still maintain that, with the exception of your
: exteamly improbable but I concede possible scenario,
: if random numbers are sent through a compression
: program, the result will in all probabitily have
: less entropy than the input file.
Assuming you mean "entropy" as a per-bit measure, you're likely
to be correct - at least when considering most common compressors.
If you consider 1-1 compressors and either the set of all possible files,
or a compressor that leaves all files above a certain size unchanged -
then it's false - which means that the original assertion that it's
false "in general" was correct.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 14:04:35 GMT
Future Beacon <[EMAIL PROTECTED]> wrote:
: Tom,
: Thank you for trying to explain this to me:
[snip]
: I don't understand it. ASCII is a seven bit code communicated in
: bytes. About a quarter of the text characters end with each of 00,
: 01, 10, and 11. [...]
There's the problem.
Only "about" a quarter is unlikely to be good enough.
It needs to be as close as a random stream would be to a quarter.
If the 00s outnumber the 11s (or visa versa) in a statistically
significant manner *here*, then they will also do so in your "RAND"
file - because this uses the same bit values as your "B" file.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Date: Tue, 27 Jun 2000 10:18:53 -0400
On Sat, 24 Jun 2000 18:57:21 -0700, tomstd
<[EMAIL PROTECTED]> wrote:
>Johnny Bravo <[EMAIL PROTECTED]> wrote:
>>On Fri, 23 Jun 2000 19:09:34 -0700, tomstd
>><[EMAIL PROTECTED]> wrote:
>>
>>>BTW Don't PGP sign all your messages. a) WASTE OF SPACE b)
>>>Don't check anyways.
>
>I hope I didn't sound like I was ordering him. Just let me
>attach the following to all my messages.
The problem is that you are not the only other person on USENET,
just because you don't check signatures doesn't mean that no one else
will. If you are that offended, consider killfiling those who sign
their messages rather than telling them to stop.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Quantum computing
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 14:15:04 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
: Hasn't expodential!=p been proven?
The question at hand is whether there exist polynomial-time solutions for
any (or all) of the class of problems thought to require exponential
quantities of work - a question that seems "obviously" false, but
for which no proof currently exists.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED]
Subject: Dynamical Cryptography algorithm
Date: Tue, 27 Jun 2000 14:13:51 GMT
Hi,
there is a new cryptography algorithm around
available on:
http://www.bccrypt.com
It is free and open source.
A full documentation (technical and also for
beginners) is available, source code explained.
Only the unix package is available for the latest
version of the algorithm and provides:
a secure chat (beta), file encryption, login apps.
As I said everything is explained on the web site
so I won't waste your time any longer, here is
just a summary of the main feature of this
algorithm:
BUGS (Big and Useful Great Security) Algorithm V
3.0.0
Private key algorithm
Dynamical cryptography algorithm
Source code can be public without making the
algorithm weak.
Multiplateform application(Unix, Windows
NT/9x/2000)
Specifities:
Infinite key length, default : 128 bits
Bilateral bits swapping with variable windows.
Bilateral Pseudo randomly binary operations.
Addition of a random number to the key
5 differents crypt's level
Seed and shuffle functions
A clear text can be crypted using its own data
2 methods of execution: direct disk access or
memory cache
Common point with the IBM algorithm : DES
Strong Key generator
Hide engine (simple algorithm)
Login application (only with the Unix application)
Secure Chat (Beta version)
Graphical Used interface for windows
Pleasedo not hesiate to contact me for further
information.
Cheers,
Sylvain.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: TEA question
Date: 27 Jun 2000 14:35:01 GMT
dexMilano <[EMAIL PROTECTED]> wrote:
> I don't have unsigned so I have an upper limit of f7777777 (absolute
> value).
You mean 7fffffff.
> Do yuo mean that I can't use this algorithm?
Get yourself a real programming language.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Remark on practical predictability of sequences
Date: Tue, 27 Jun 2000 07:50:57 -0700
To me this seems clearly true. But what are you getting at?
Mok-Kong Shen wrote:
> Pseudo-random sequences, being deterministically generated,
> always involve the issue of predictability. On the other
> hand, a good cipher prevents the opponent to obtain the
> plaintext from the ciphertext. It seems logical to conclude
> that, if one feeds a pseudo-random sequence to a good cipher,
> the resulting output sequence is practically unpredictable,
> since he can't recover the original sequence which he needs
> to do the inference in the first place.
>
> I should appreciate comments on this view.
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
