Cryptography-Digest Digest #173, Volume #10 Sat, 4 Sep 99 06:13:03 EDT
Contents:
Re: Ways to steal cookies in HTTP and HTTPS (John Pliam)
Re: NSA and MS windows (Red_Blue)
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: More information on TEA available? (JPeschel)
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: NSA and MS windows ("Roger Schlafly")
Re: Cracked ? (JPeschel)
Re: Cracked ? (pbboy)
Re: 512 bit number factored (Peter L. Montgomery)
Re: Cracked ? (Jeremy Fincher)
Re: NSA and MS windows (Ralf Stephan)
Re: NSA and MS windows (pbboy)
Re: NSA and MS windows (SCOTT19U.ZIP_GUY)
Re: SQ Announcement ("Kostadin Bajalcaliev")
----------------------------------------------------------------------------
From: John Pliam <[EMAIL PROTECTED]>
Crossposted-To: comp.infosystems.www.misc,comp.security.misc
Subject: Re: Ways to steal cookies in HTTP and HTTPS
Date: Sat, 04 Sep 1999 06:00:48 +0000
Barry Margolin wrote:
> In article <[EMAIL PROTECTED]>,
> isoma <[EMAIL PROTECTED]> wrote:
>
> > I understand that some sites use cookies to store sensitive
> > information, but not the mechanism by which a malicious site
> > owner obtains it.
>
> I think the original post presumed that the malicious site
> was spoofing traffic from the site you were connecting to, and
> inserting HTML tags that would cause your browser to connect
> to his site for some images and send your cookie information
> to him as part of that transaction. That's why he's concerned
> about 3rd-party cookies.
As the original poster, I must apologize for losing this thread
in the sea sci.crypt traffic.
Right, the *active* attacks in the original post
http://www.ima.umn.edu/~pliam/cky
aren't particularly impressive against http cookies which are
already "insecure". They require the adversary to actively
spoof traffic between Client and Server1 *while* simultaneously
passively listening to the traffic (the desired cookie) between
Client and Server2.
However for https cookies, the work factor
2^128 >> (2^40 + some active attacks),
and there is a distinct advantage gained (unless the user
*never* enables SSLv2 or 40-bit-only SSLv3 which is unlikely
in today's world).
John
------------------------------
From: Red_Blue <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 09:33:55 +0300
Bruce Schneier wrote:
> Suddenly there's a flurry of press activity because someone notices
> that the second key is called "NSAKEY" in the code. Ah ha! The NSA
> can sign crypto suites. They can use this ability to drop a Trojaned
> crypto suite into your computers. Or so the conspiracy theory goes.
First of all, implementations that don't use CryptoAPI are secure from
this, such as SSL and S/MIME in Communicator, and PGP. So only fully MS
made security systems are affected because they have two trusted "root"
keys instead of one. Right?
The question is what actual methods of attack could be used to exchange
the current Microsoft RSA Base Provider CSP module used by Explorer or
Outlook with a weakened one that is signed with a key replaced by the
attacker? And would this attack be so much more difficult than an attack
which disables the verification instead of changes one of the two keys,
that it would constitute a significant increase in actual risk of this
kind of "weaken-the-crypto-suite-attack"?
Jere Hakanen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Fri, 03 Sep 1999 23:41:25 -0700
David A Molnar wrote:
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
> > I *WILL* point out that design of block ciphers is not exactly brain surgery in
> > this day and age. This is a field which is, to a certain extent, mature, unlike
> > the field of public key encryption, which is still in its infancy.
> ^^^^^^^^^^^^^^^^^^^
>
> Because we only have a few trapdoor one-way functions ?
>
> Why are block ciphers more mature, if DES and Lucifer are only 5-10 years
> older than Diffie-Hellman? are you counting the Enigma and PURPLE
> as early block ciphers in the sense they're considered today?
Well, block ciphers are basically a derivative of the whole concept of
machine ciphers, something which goes back to at least the late 30's.
Whereas public key encryption as a concept does not appear to pre-date
the mid 70's. It has only been within the past twenty years that public
key encryption has really been explored and undoubtedly there's a lot
more that will be done in the area before we can consider it to be
"mature".
As an example of the maturity of the block cipher concept, the AES
candidates use a variety of different "machine" mechanisms to do their
various shifting and masking and feedback and etc. operations, but the
underlying concept is still the same and none of the mechanisms can be
regarded as particularly novel (i.e., they've all been explored in the
literature before, at least in some close variant form). Key recovery or
plaintext recovery for all of these algorithms is, as far as we know,
equally difficult, and the possible attacks are fairly well known (at
least by the NSA, which undoubtedly knows of more attacks than we do,
but probably not many more since math is math no matter how many
mathematicians you have on staff).
By contrast, the various public-key algorithms use different "hard
problems" as their basis, possible attacks are fairly well known for RSA
but elliptic and exponential curves have not yet recieved the same level
of attention, and cryptographic strength vs. keylength varies widely
between the algorithms. There does not even appear to be agreement on
what constitutes a "strong prime" and whether one is needed for RSA
between the sources that I've consulted so far (granted, I have by no
means read all the available literature, you'll have to excuse me, I'm
reading as fast as I can!). And RSA is the most-analyzed of all the
public key algorithms, so if we can't even agree on that kind of
niggling detail, it's hard to call the field mature.
This isn't to say that public key encryption is insecure, just that our
knowledge of how to attack the underlying "hard problems" and the basic
implementation details needed to forestall those attacks are still areas
of VERY active research.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Sat, 04 Sep 1999 00:05:29 -0700
"SCOTT19U.ZIP_GUY" wrote:
> I don't think it is that mature yet. Yes will have computers and we can
> measure things for certain forms of attack. But we aren't there yet. I still
> think it is foolish to use short keys and any block less than the largest
> possible.
Well, in my case I am not encrypting top secret data, I am encrypting
data sent over a public network, in real time if possible. Thus using a
key longer than 128 bits just won't do it with today's computers, which
just aren't fast enough. Even with 128 bit Blowfish, a fairly fast
algorithm, I can see a significant performance drop over just doing,
e.g., a plain FTP transfer. In fact, on my machine (a K6/2-333), I can
do an FTP transfer basically as fast as my hard drive will go, but using
Blowfish with 'ssh' gets me down to around 400K per second.
I agree that for sensitive data you should encrypt it with the longest
key and largest block size that are computationally feasible, even if no
known attack will be able to break it within a reasonable amount of
time. It's just that the definition of "computationally feasible"
depends upon your application. CPU power is limited. In addition, you
should be careful to use an efficient algorithm for time-critical
operations. For example, Triple DES is a pig, use RC5 or Blowfish or any
of the AES finalists (the finalists appear to be the fastest of the
submitted algorithms, which makes sense if you assume that, in a mature
field like block ciphers, all of the algorithms had similar
cryptographic strength). My understanding is that the typical criticism
of your program is that it's rather slow for the amount of cryptographic
strength provided.
> Most people think I am kidding but when it comes to AES don't any of
> the so called creditable crypto people think that it is just a front for
> the NSA or are they all so caught up in the excitement they stop
> thinking.
The problem is that, as I've browsed the web looking for crypto sites,
I've found a lot of people who have looked at the AES candidates, people
who have done algorithms of their own or at least implemented the major
algorithms and presumably know what they're doing. The finalists appear
to be the ones that were fastest and easiest to implement (or in the
case of Twofish, complex to implement but also rather flexible, one guy
referred to it as an "engineer's cipher" because of the way it could be
optimized differently for different applications). I've seen plenty of
criticism of the AES contest, even some of the folks who've contributed
candidates have said that AES should be a family of algorithms rather
than a single algorithm, but few signs that the NSA has somehow
"trojaned" the contest (unless RC6 is a trojan, but if RC6 is a trojan,
then so is RC5, from which it apparently is derived, and as far as I can
tell RC5 seems to be considered secure). The NSA's choices for finalists
seem to be pretty close to what the public community predicted before
the finalists were announced.
In addition, at least two of the AES candidates are based on prior work,
i.e. RC6 is basically a derivative of RC5, and Twofish is a derivative
of Blowfish. Both RC5 and Blowfish have been hit on pretty hard, making
it unlikely that their derivatives have a weakness that would allow
anybody to crack them in significantly less time than is currently
conjectured.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: More information on TEA available?
Date: 04 Sep 1999 07:27:46 GMT
<[EMAIL PROTECTED]> writes:
>I'm somewhat fascinated by the brevity of TEA, it's a dream to code and use.
>I'm looking for up-to-date information on the strength of TEA, and any other
>new information that might have surfaced about it.
>
>Any links you can recommend?
http://www.cs.berkeley.edu/~daw/papers/keysched-icics97.ps
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Sat, 04 Sep 1999 00:10:36 -0700
Bruce Schneier wrote:
> On Fri, 03 Sep 1999 21:42:57 GMT, Eric Lee Green <[EMAIL PROTECTED]>
> wrote:
> >As for documentation, there is an *ENTIRE BOOK* with documentation for TwoFish,
> >not to mention extensive documentation online at the AES home page. If you're
> >too cheap to buy the book, don't look for sympathy in these quarters.
> The entire book is on the website. Only buy the book if you want a
> bound copy; if you just want the information, download it for free.
Ah. I had the book already (it was sitting on the shelf at the bookstore
alongside "Applied Cryptography" and the company was buying so I threw
it into the shopping bag), so I didn't download the online documentation
for TwoFish to see whether it was the same. Makes sense, though. I've
already come across at least one overseas reimplementation of TwoFish
that uses nothing but the AES-submitted documentation with no access to
the source code, so obviously it has to be complete.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Sat, 4 Sep 1999 00:15:13 -0700
Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
>I see two possibilities. One, that the backup key is just as
>Microsoft says, a backup key. It's called "NSAKEY" for some dumb
>reason, and that's that.
Maybe. Perhaps someone from the NSA suggested using a
backup key, and the MS programmers called it the NSA key.
>Two, that it is actually an NSA key. If the NSA is going to use
>Microsoft products for classified traffic, they're going to install
>their own cryptography. They're not going to want to show it to
>anyone, not even Microsoft. They are going to want to sign their own
>modules. So the backup key could also be an NSA internal key, so that
>they could install strong cryptography on Microsoft products for their
>own internal use.
I doubt it. I can understand NSA not wanting to show its crypto
module to MS, but it wouldn't have to anyway. If the NSA wants
a CAPI module signed, all it has to do is to give an MD5 hash
to MS, and MS returns a signature. Quick, and revealing nothing.
I think this second explanation only makes sense if it is part
of some NSA scheme to plant bogus CAPI modules somewhere.
Legitimate modules could be signed in the normal way.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Cracked ?
Date: 04 Sep 1999 08:05:01 GMT
<[EMAIL PROTECTED]> writes in part:
>Can someone give me a list or tell me where to find it of
>all common encryption-algoritms that are cracked...
Peter Gutmann lists from my web page:
Arj, BIOS passwords, Compuserve, Contraband 9G, Crypt-o-Text, Cryptic Writer,
CuteFTP, CyberSitter, Encrypt-It, Eudora, MS Access, MS Word, MS Excel, Norton
Diskreet, Novell Netware, RAR, 40-bit S/MIME, Stacker, Turbo Encrypto,
Wincrypt,
Windows NT password, WordPerfect, WS_FTP, and Zip.
I might add: UBE 98 (two versions), File Locker, WinXFiles, Windows screen
savers.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: pbboy <[EMAIL PROTECTED]>
Subject: Re: Cracked ?
Date: Sat, 04 Sep 1999 04:43:57 -0400
JPeschel wrote:
> <[EMAIL PROTECTED]> writes in part:
>
> >Can someone give me a list or tell me where to find it of
> >all common encryption-algoritms that are cracked...
>
> Peter Gutmann lists from my web page:
>
> Arj, BIOS passwords, Compuserve, Contraband 9G, Crypt-o-Text, Cryptic Writer,
> CuteFTP, CyberSitter, Encrypt-It, Eudora, MS Access, MS Word, MS Excel, Norton
> Diskreet, Novell Netware, RAR, 40-bit S/MIME, Stacker, Turbo Encrypto,
> Wincrypt,
> Windows NT password, WordPerfect, WS_FTP, and Zip.
Encrypt-It?! Who wrote that program? What is the address of this web page you
write of?
pbboy
------------------------------
From: [EMAIL PROTECTED] (Peter L. Montgomery)
Subject: Re: 512 bit number factored
Date: Sat, 4 Sep 1999 08:40:58 GMT
In article <[EMAIL PROTECTED]> Anton Stiglic <[EMAIL PROTECTED]> writes:
>DJohn37050 wrote:
>
>> It still seems that RSA Labs may not have recommended increasing the key size
>> of RSA keys beyond 512 bits until 1995. If someone can find an earlier date,
>> please report it. But if that is the case, then it is only a few years.
>> Don Johnson
>
>I would also be interested in seeing such an article! An article that "backs
>up" its
>statements.
I was one of 16 participants at a July, 1991, workshop on
Public-Key Cryptography sponsored by E.I.S.S.
(European Institute for System Security). Our report appears in
Th. Beth, M. Frisch, G.J. Simmons (Eds.)
Public-Key Cryptography: State of the Art and Future Directions,
Lecture Notes in Computer Sciences, 578,
Springer-Verlag, 1991.
Page 81 of this report says
For the most applications a modulus size of 1024 bit
for RSA should achieve a sufficient level for ``tactical''
secrets for the next ten years. This is for long-term
secrecy purposes, for short-term authenticity purposes
512 Bit might suffice in this century.
Page 39 of that report estimates 500,000 MIPS-years
to factor a general 512-bit integer via ppmpqs.
The number field sieve was rather new in 1991 (it had been
used to factor 2^512 + 1 but some thought it impractical
for general numbers). Nonetheless page 44 of the report warns
Thus is it not unlikely that the number field sieve is better
than the ppmpqs for factoring integers in the 512-bit range.
[an understatement -- the 8000 MIPS-years for gnfs is under 2%
of the ppmpqs estimate!]
The 1991 recommendation for 1024-bit keys is still valid in 1999.
The report makes no recommendation for key lengths next century.
--
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: [EMAIL PROTECTED] (Jeremy Fincher)
Subject: Re: Cracked ?
Date: 04 Sep 1999 09:17:33 GMT
>> <[EMAIL PROTECTED]> writes in part:
>>
>> >Can someone give me a list or tell me where to find it of
>> >all common encryption-algoritms that are cracked...
>>
>> Peter Gutmann lists from my web page:
>>
>> Arj, BIOS passwords, Compuserve, Contraband 9G, Crypt-o-Text, Cryptic
>Writer,
>> CuteFTP, CyberSitter, Encrypt-It, Eudora, MS Access, MS Word, MS Excel,
>Norton
>> Diskreet, Novell Netware, RAR, 40-bit S/MIME, Stacker, Turbo Encrypto,
>> Wincrypt,
>> Windows NT password, WordPerfect, WS_FTP, and Zip.
>
Where can the information be found as to how (scientifically) these were
cracked?
Jeremy
==================================
If i ever forget to capitalize a proper noun, forgive me. i'm a big fan of ee
cummings
My ICQ # is 28153190. My AIM/AOL name is either jemfinch02 or Cassius80.
Have a good day, and good luck in your endeavors!
------------------------------
From: [EMAIL PROTECTED] (Ralf Stephan)
Subject: Re: NSA and MS windows
Date: Sat, 4 Sep 1999 11:13:12 +0200
Thomas J. Boschloo:
>Bruce Schneier wrote:
>[argument for MS stupidity]
>So that leaves possibility 'one':
>
>> I see two possibilities. One, that the backup key is just as
>> Microsoft says, a backup key. It's called "NSAKEY" for some dumb
>> reason, and that's that.
But then, MS could have easily confirmed that, instead of
making yet another foggy statement (see sig from Wired).
Maybe, if 1 is true, we see the first real hiccup in MS's
spin control machine --- the Halloween papers were not quite
as disturbing as this.
As others said, now is the time to open the source.
ralf
--
http://www.in-berlin.de/User/rws/
"_NSAKEY signifies that it satisfies security standards." (Microsoft)
------------------------------
From: pbboy <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 05:47:09 -0400
NSA : "P-p-p-please sign this thingamajig, Mr. Gates. I'll do anything
you want...I'll be your best friend...!"
Gates: "HA! Lick my feet! Bow to me, the omnipotent Gates!"
NSA: *Lick-lick-slobber-slobber* (wipes crusties from mouth, removes gum
from forehead) (*sniffling*)"Now w-will you sign it?"
Gates: "No! Do it again, just so you know who's boss!"
I don't think so.
Maybe I overestimate the NSA's power, but why would the NSA _ask_ MS for
anything?!? This is a game, people! Why hack/crack/reverse-engineer
anything? The NSA has soooo much influence, and even more power they don't
need permission for anything like this. Here's the way I would obtain
anything from anyone, including MS.
Moles
1) Recruit some young brilliant software engineer, one that even MS would
fight for.
2) Send him on a mission: Get recruited by MS (they hire by the bus-load,
i hear)
3) lay low for a while, gaining trust (read: security clearance) from the
Company.
4) Somehow get assigned to the "encryption and security" (hehe!) task
force
5) keep head quarters (NSA) informed about the direction the company is
taking towards its security =) features
6) Hand over the source and any other info pertaining to the mission.
7) remain in MS as long as possible, divulging as many secrets and as much
dirty laundry as possible (NSA just LOVES secrets!) Could lead to future
extortion / blackmail / bribery of high ranking executives ect..
8) Gain as high a position as possible in the Company to have a more
direct influence over it and its future
Espionage, corporate espionage. now that's fun!
I don't doubt for one second the above scenerio, or a similar one, hasn't
happend yet or is taking place as we type.
OR
Maybe I underestimate MS's power....
========
pbboy
HEHE! Do you really think, IF the NSA were to use any MS products, they
would actually pay for the licenses? Do ya think the NSA has a software/OS
engineering department of their own?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 10:47:49 GMT
In article <7qqgs3$oan$[EMAIL PROTECTED]>, "Roger Schlafly"
<[EMAIL PROTECTED]> wrote:
>Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
>>I see two possibilities. One, that the backup key is just as
>>Microsoft says, a backup key. It's called "NSAKEY" for some dumb
>>reason, and that's that.
>
>Maybe. Perhaps someone from the NSA suggested using a
>backup key, and the MS programmers called it the NSA key.
>
>>Two, that it is actually an NSA key. If the NSA is going to use
>>Microsoft products for classified traffic, they're going to install
>>their own cryptography. They're not going to want to show it to
>>anyone, not even Microsoft. They are going to want to sign their own
>>modules. So the backup key could also be an NSA internal key, so that
>>they could install strong cryptography on Microsoft products for their
>>own internal use.
>
>I doubt it. I can understand NSA not wanting to show its crypto
>module to MS, but it wouldn't have to anyway. If the NSA wants
>a CAPI module signed, all it has to do is to give an MD5 hash
>to MS, and MS returns a signature. Quick, and revealing nothing.
>
>I think this second explanation only makes sense if it is part
>of some NSA scheme to plant bogus CAPI modules somewhere.
>Legitimate modules could be signed in the normal way.
Surely the NSA would never attemp anything like that.
I wonder how many people will be switching to Linux in the
next few weeks. Does any one really trust what others gems
Bill and the NSA have up there sleves. It may be fun to
watch MSFT ( I hope this is correct symbol for them) stock
the next week. I for one am lucky enough not to have any
stock in them. But only becasue of moral reasons.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: SQ Announcement
Date: Sat, 4 Sep 1999 10:45:11 +0200
>It certainly sounds like you are tackling the right problems. If we
>had a theory that could provide proofs of security (or design principles)
>for RC4-like ciphers, that would be extremely interesting.
>
>However, I don't yet understand how the theory you are describing works.
>Again, this may be just a communications problem.
First of all Shanon theory apply to Block Ciphers too, when they are used in
OFB mode, but as much as I know no one can compute the key (of RC5 for
example) just having couple of ciphertext blocks. The second thing, there is
nothnig as "no bounds on our computing power".
About the theory, I let me try again to explain it. Let C(x) is some
self-mutating stream cipher (RC4 like). The key by definition is unknown,
the only thing we have is the output sequence. In order to revers a single
round we need information G. This is the needed quantity of information. On
other hand we have the information carryed by the output sequence B. B is
the maximum quantity of information we can destiled from the output sequence
about the inner state of the generatort. If G>B than the rest G-B is unknow,
that is the "lost" information that we need to predict because there is no
other way. And the whole point is how to design a stream cipher so there to
be enought "lost" information so it can be secure. This theory is how to
make a cipher to be something as solving system of 6 equants with 7
unknowns. Here is part of the thesis (which you should read)
===============================
In all classic books about Cryptography you can find that there is no secure
algorithm, only they can be more or less complex to break. I am going to
show that it is possible to design provably secure algorithms. The output
sequence and all the details about the algorithm are unconditionally
available to the attacker. Attacker do not know the state of algorithm, his
objective is to reconstruct generator state so he can produce any further
output. Because setting the initial state is in fact SC keying, the last
statement mean that attacker can not know the key. This is the standard
assumption about security, only unknown is the key, the whole security of
the algorithm relay on the secrecy of the key.
Classical approach to solve this problem is by making the algorithm to be a
complex function of transformation, having pairs x, F(x) (just to remained
that every SC is xk=F(xk-1)) is not enough to reconstruct F in a given
point. But using only this approach we are always forced to make assumptions
about security, putting the security of the design on the hardness to solve
or invert some mathematical construction.
Before I define my idea how to make provably secure SC, here is a little
illustration story.
Old Puzzle Problem
There is a puzzle, a very old one, and someone is trying to solve it. But
the bricks are old and damaged, so it is hard to distinguish their forms for
sure. Two originally different parts are now almost the same and we can not
do anything to found their original form. We try to predict the original
form of the bricks but there are so many of them. Also the colors are
damaged. Some bricks are in better condition and we have a general idea what
the puzzle was, but we can never say it for sure.
I am using this museum story to introduce the using of the same idea in SC
design. For example, there is a PRBG with 8 bits output per iteration, if we
discard one of them we get 7 bit value (I call this �secondary output�), so
the output sequence constructed does not carry the whole information about
the generated output values. Having xk=F(xk-1); 8 bit generator, discarding
the first result is ZYYYYYYY, where Z is the discarded bit. Let Z�XXXXXXX
and Z��YYYYYYY be two successive values connected by Z�YYYYYYY=F(Z��
XXXXXXX); but Z� and Z�� are unknown so there 4 different equates and only
one of them is the true.
0YYYYYYY=F(0XXXXXXX);
0YYYYYYY=F(1XXXXXXX);
1YYYYYYY=F(0XXXXXXX);
1YYYYYYY=F(1XXXXXXX);
It is impossible to mathematically found which is the true one if Z is
unknown. Prediction can be made but that is equal to the problem of guessing
the original form of the puzzle brick. If the generator output is 32bit but
only one bit from each generated value is used to form the output sequence,
then guessing these 31 missing bits is practically impossible.
This is the �information loss� approach to solve the security problem about
SC. Because the output available to the attacker does not carry the whole
information needed to apply some attack he can not do it. He can not do it
even if he found some efficient approach to break it in its pure form. This
approach is done using the 4th assumption about randomness from the
beginning of this thesis.
==============================
------------------------------
** 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
******************************
