Cryptography-Digest Digest #143, Volume #14 Sat, 14 Apr 01 18:13:01 EDT
Contents:
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Concerning United States Patent 4979832 (Dynamic Substitution) (Terry Ritter)
Re: _"Good" school in Cryptography ("was" I got accepted) (newbie)
Re: LFSR Security ("Tom St Denis")
Re: LFSR Security (David Wagner)
Re: Rabin-Miller prime testing (Bryan Olson)
Function other than xor? (newbie)
Re: How to use Dynamic Substitution (Terry Ritter)
Re: Function other than xor? (newbie)
Re: Dynamic Substitution Question (Terry Ritter)
Re: MS OSs "swap" file: total breach of computer security. ("AY")
Re: LFSR Security ("Tom St Denis")
Re: MS OSs "swap" file: total breach of computer security. ("Tom St Denis")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sat, 14 Apr 2001 21:16:09 GMT
On Tue, 10 Apr 2001 07:35:38 GMT, in <eJyA6.7$3d3.124@interramp>, in
sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:
>Terry Ritter wrote:
>>
>>On Sat, 07 Apr 2001 06:24:00 GMT, in <4oyz6.6$4G.143@interramp>, in
>>sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:
>>
>>>In article <[EMAIL PROTECTED]>, Terry Ritter wrote:
>>>>
>>>>On Wed, 04 Apr 2001 19:53:09 -0700, in
>>>><[EMAIL PROTECTED]>, in sci.crypt Bryan Olson
>>>><[EMAIL PROTECTED]> wrote:
>>>>
>>>>>Bryan Olson wrote:
>>>>>> > Terry Ritter wrote:
>>>>>
>>>>>> > >The "second data source" is modified by said "result data" before use,
>>>>>> > >but no part of the claims excludes that possibility.
>>>>>> >
>>>>>> > The word "source" excludes the possibility. The sequence of
>>>>>> > y values is in fact a _product_ of the substitution process,
>>>>>> > not a source. If unclear of the interpretation of "source",
>>>>>> > just read the background and look at the diagrams in the
>>>>>> > patent.
>>>>>
>>>>>> Any sequence of data values is "a source." We can see this
>>>>>> throughout the patent, including: "A first data source and
>>>>>> a second data source are combined into a complex
>>>>>> intermediate form or result. . . ." Note the lack of
>>>>>> description about the "ultimate" origin of any data sequence
>>>>>> treated as a "source."
>>>>>
>>>>>It may be any sequence of values, but it must be a source,
>>>>>not a product. Neither does the ultimate origin matter;
>>>>>just that it comes in from the outside.
>>>>
>>>>The ultimate origin is of course outside *the* *combiner*, but not
>>>>necessarily outside the system containing the combiner.
>>>
>>>The source in question is produced _from_ the table as the
>>>"combiner" updates it.
>>
>>That's fine with me. The Dynamic Substitution claims place no
>>limitations on the source of these values.
>
>Right. But it's not a source. It's a product of the same
>table.
No problem. It *becomes* a source.
>>>>When you present a system which is more than just the combiner, I am
>>>>free to select what signals there are and try to match them to a
>>>>claim. You don't get to decide what signals I select. You can add
>>>>whatever you want around an invention in an attempt to obscure which
>>>>parts actually constitute the invention, but the invention is still
>>>>there somewhere, and I get to find it.
>>>
>>>Exactly. The sequence _you_ chose depends upon the dynamic
>>>update of the table. It is necessarily a function of the
>>>combiner, and cannot be outside.
>>
>>I have no idea what your point may be. The claims do not specify a
>>particular origin for the sequences.
>
>It's not a combiner of data sources. It's producing one
>from state alone.
It is combining two parts of that RNG state.
>>>>>> But, if you don't like the word "source," perhaps you would
>>>>>> prefer the word "value": [...]
>>>>>
>>>>>Which is not the word in the claim at issue.
>>>>
>>>>It only takes one claim. Any claim counts.
>>>
>>>The one you had cited is claim 1. If you want to instead go
>>>through claim 15, note that it's not only a "value" it's an
>>>"input value". Claim 15 also states one output, and if you
>>>use that value for the output, the cipher cannot function.
>>
>>I *think* the intent here is to recall an argument made earlier that
>>"the cipher" has an XOR combiner, so "the" combiner obviously is not
>>DynSub.
>
>Not really. You tried to show claim 1 fit; then when I
>argued it didn't, you appealed to the wording of a different
>claim.
When the question is whether the patent covers whatever, any claim
counts.
>[...]
>>>From "actual words from a claim" to what you are happy with
>>>is a huge change.
>>
>>Fine. So what?
>
>So I said the standard changed and you disagreed. If it's
>a "so what" then fine.
It's an expected consequence of the ground rules I stated in the
beginning: we cannot remove legal judgment -- which requires a
background in the law and the rules -- from the debate. The closer
one gets, the more the issue depends on those rules instead of
technology, and the less sure I can be.
In fact, there is no point in doing this. If someone wishes to avoid
Dynamic Substitution, they know how to do it. If someone wishes to
come as close as possible to test the law, they know how to do that as
well. It doesn't depend upon me at all.
>>I started out this endless river of text by pointing out that the
>>interpretation of an issued patent is a *legal* issue, not a technical
>>one, and you responded to that with something deliberately intended to
>>have me address the technical issues -- under those conditions.
>
>This is a "sci" group and I'm not interested in armature
>lawyering. The legal issues have not even come up. In the
>case of recent proposed cipher, no one is using it, or
>making or selling any product that includes it. It's a
>technically flawed symmetric cipher so doubtless it will
>remain unused. In the case of RC4, millions of people use
>it and many products include it.
Really? Where do you get your information? How about a few names and
addresses?
>Despite some assertions
>about trade secrecy years ago, the actions that might raise
>legal issues simply do not exist.
Perhaps you can testify from your personal knowledge of the trade
secret cipher, but I can't. All I know is rumor.
>>However, not being a patent attorney, not being fully conversant with
>>all law, PTO rules, and especially case decisions, I simply cannot
>>provide an authoritative interpretation to close calls. The closer
>>one gets to trying to be close to DynSub without actually reading on
>>the Dynamic Substitution patent, the more risk there will be in any
>>technical decision. People can avoid that risk by not trying to use
>>Dynamic Substitution without licensing Dynamic Substitution, and it's
>>as simple as that.
>
>Agreed.
>
>
>>>>The body of the patent is used as a dictionary to interpret the
>>>>meaning of words used in the claims. I have quoted several times
>>>>where it does not support your interpretations.
>>>
>>>You have quoted such zero times. I never said it couldn't
>>>be used to combine confusion sequences, or the various
>>>things you cited.
>>
>>*I* have to follow and respond to -- what? -- 8 or 10 different
>>threads, and I am not going to necessarily put every quote in every
>>thread. If you don't read all I write, you are going to miss out. If
>>you want to keep talking, you have to do at least as much homework as
>>me, and you are behind.
>
>Done. (Well, I think so - my news server sucks.) I stand by
>my reporting.
The issue wasn't "reporting," the issue was asking questions which had
been asked and answered.
>>Now, I have thought about this some, and I am now much happier with
>>the idea that this is a peculiar and stilted form of Dynamic
>>Substitution. That doesn't make it so, that is just my opinion. But
>>if somebody really wants to know whether such a design reads on the
>>patent, I think it does.
>
>Very well. My opinion differs. Since the proposed cipher
>is not likely to see use, that may be as far as we get.
>
>
>>However, the real purpose of the exercise was for you to present code
>>that is almost like some very well known code, and for me to say,
>>"Yes, that is Dynamic Substitution," so that you can ridicule anything
>>which is that close to what is commonly known.
>
>The purpose was to show that the claims have to "fit" much
>more closely than you seem to think. Shuffle doesn't
>combine two data sources; it takes just one.
To understand how prior art is applied -- and whether any such
decision is "correct" -- requires some background in the PTO rules.
Patent examiners live with those issues day in, day out, through their
working lives.
Shuffle was not hidden from the examiners, but was instead presented
in the application as part of the prior art. It was examined and a
decision made that Dynamic Substitution distinguished beyond that art.
And while it possible that you understand the PTO rules affecting
prior art better than the examiners, I don't think that likely.
A decision has been made. If you are going to say it was wrong, you
will have to cite chapter and verse in nothing less than a detailed
legal argument. And it won't take much of that before you are beyond
any comment from me.
>[...]
>>>>>> It is implied throughout the patent body that there is no such
>>>>>> limitation.
>>>>>
>>>>>What text from claim 1 implies that? How about claims 2, 7
>>>>>and 8? Didn't you also write:
>>>>
>>>>It doesn't matter. Any one claim counts. It is only necessary for
>>>>all aspects of any one claim to be satisfied for a design to read on
>>>>the claim.
>>>
>>>Agreed. But you have no such claim.
>>
>>Claim 1.
>>
>>I don't even know what any of this refers to anymore, and I have
>>looked back through the quotes and gotten remarkably little help. So
>>I *think* this is about whether the claim 1 covers RNG combining and
>>maybe also the question of table invertibility.
>
>It refers specifically to a post of yours from April 2.
>Here's the "fit" at issue:
>
> >Here's the proposed modified RC4:
> >
> >byte x, y, z, sbox[256];
> >encipher(byte data) {
> > x = (x + 1) & 255;
>
> Here x might be the "first data source."
>
> > y = (y + sbox[x]) & 255;
>
> Here y might be the "second data source," and sbox[] might be the
> "substitution means for translating values from said first data source
> into said result data or substitute value."
>
> The "second data source" is modified by said "result data" before use,
> but no part of the claims excludes that possibility. Quite the
> contrary, as we see . . . .
>
>The y is not a source; the sequence of values is product of
>the table state and cannot be produced outside the combiner.
>The x isn't really a source either.
They are sources with respect to the combiner.
>>Much has been said about this on other threads:
>>
>>First, generally speaking, only the things particularly specified in a
>>claim must be present for the design to read on the claim. Here is
>>claim 1, yet again:
>
>Using the rest of the patent as a dictionary, we see that
>"data source" is used as usual in the description of
>algorithms. The "fit" dosn't.
Sure it does.
>[...]
>>Anyone who questions the meaning of terms in the claims is referred
>>back to the specification for clarification. With respect to
>>combining RNG sources and non-invertible tables, we have:
>
>Exactly.
>
>>"The combiner can also be used to combine two pseudo-random confusion
>>streams into a more-complex confusion stream.
>
>How is that relevant? Are you going to say that x, which
>steps through the table locations sequential order is a
>confusion sequence? There is no confusion sequence there
>until it is produced from the table state.
What "I am going to say" is that the code is intended to generate a
sequence of x values; that is a sequence, and a source.
>[...]
>>"Another use for a dynamic substitution combiner would be to combine
>>two different pseudo-random sources. This would generate a
>>more-complex pseudo-random combination, and would also help protect
>>both input sources from analysis better than the simple exclusive-OR
>>combiner generally used. In this case, an extractor would generally
>>be unnecessary, since the same combined result could be reproduced by
>>generating the original pseudo-random sources and combining them."
>>
>>"The same mechanism can function with either data or confusion values
>>on either input, depending on the goals of the designer. Two confusion
>>sources might be combined to make a more complex result, and even two
>>data sources might be combined for some reason.
>
>The mechanism here, the stuff inside the section you chose
>to match to the claim, is not combining two pseudo-random
>source, nor confusion values and plaintext.
And neither is required; all that is required is that it combine two
sequences, two sources. The character of the sources is irrelevant.
>It's producing
>one source from the table state. It is not, and does not
>use, the invention disclosed in your patent.
The limits of a patent are the claims. It is not necessary to
describe a particular application in detail in the specification to
enforce a claim which reads on it. But of course the specification in
this case did clearly describe the use of combining RNG sequences.
Personally, I think it does read on the claims. I have no idea what
the legal issues might or might not be.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Concerning United States Patent 4979832 (Dynamic Substitution)
Date: Sat, 14 Apr 2001 21:16:58 GMT
On Wed, 11 Apr 2001 15:37:20 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt Ken Savage <[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>
>> As I quote from that patent: "Each data value from the first data
>> source is transformed by substitution using one of potentially
>> multiple translation tables. The translations within each table can be
>> changed after each substitution operation using a changes controller.
>
>*CAN* be changed. OTOH, it *CAN* be left alone. Thus a simple
>substitution
>cipher where out=sbox[in] would violate this claim. Ick.
If you are going to show your disgust for the patent, you need to
discuss what the patent really controls, instead of some made-up
bogeyman.
Every technical person needs to understand patents a great deal better
than indicated above. The controversial text is not a claim. It is
from the specification -- the body text, the teaching area.
It is difficult to introduce concepts in ways which cannot be
misunderstood. The intent in this instance was to distinguish from
"changing after each substitution operation," since the exact same
function can be performed by updating the table less often, but more
intensively.
One option is to allow used translations to accumulate until one is
needed again, and to only then update the table.
Protecting against this possibility is just protecting the original
patentable concept.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: _"Good" school in Cryptography ("was" I got accepted)
Date: Sat, 14 Apr 2001 17:24:10 -0300
You have to be anarchist :)))
Olga was anarchist.
"M.S. Bob" wrote:
>
> newbie wrote:
> >
> > Your first postulate is : "the university is the only place when you can
> > learn cryptography "
> > Your second is " you have to be strong mathematician to learn
> > cryptography "
> > Your third postulate is " only USA and Europe are the best place to
> > learn cryptography"
> >
> > This is simply wrong.
> >
> > Did you read a french translation of "Stop secret" Tchayatin Olga?
> > Unpublished book. It is hard to find.
> > I have a copy but not in Canada. In my sister,s house in Paris.
>
> If you're willing to lend it to me, I'll pick it up from your sister's
> house in Paris sometime.
> Assuming your copy is the french translation.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 21:43:35 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9badf7$gkb$[EMAIL PROTECTED]...
> Nathan E. Banks wrote:
> >> [...] Berlekamp-Massey [...]
> >
> >Is there an explanation anywhere that's a bit more straightforward than
> >the one in Handbook of Applied Cryptography?
>
> Not that I know of. It's deep magical stuff for me too.
That can't be! Most of the time I view you guys (Knudsen, Massey, Vaudenay,
Schneier, You...) as brilliant geniuses... Admitting it's magical is just
wrong! j/k
> Still, here's something that might help. Berlekamp-Massey applies
> even when the taps are unknown, but let's take the simpler case where
> the taps are known. Suppose our register is n bits long, and we have
> n bits of known keystream, call it z. Let k be the initial state of
> the register. Then we can write z as a linear function of k. In
> particular, there is a matrix M so that z = Mk. Note that M depends
> only on the taps of the LFSR, so we can write it down. Then we can
> use Gaussian elimination to compute the inverse M^{-1} of M, and the
> equation k = M^{-1} z will allow us to recover k from z. This shows
> how to break a LFSR where the taps are known.
Question: Does the BM algorithm apply when non consecutive outputs are
known?
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 14 Apr 2001 21:51:48 GMT
Tom St Denis wrote:
>Question: Does the BM algorithm apply when non consecutive outputs are
>known?
I don't know. The standard formulation requires 2n bits of consecutive
known keystream, but I don't know whether their techniques can be extended
to handle the case where the known keystream bits are not consecutive.
It's an interesting question....
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Rabin-Miller prime testing
Date: Sat, 14 Apr 2001 14:45:27 -0700
Benjamin Johnston wrote:
> I've got another question... what the "standard" practice is for generating
> values that act as a "witness" for a prime?
>
> The explanations of Rabin-Miller that I managed to find all implied that
> these values should be generated randomly.
Yes, so that we apply the following theorem: No composite
passes the random-base Miller-Rabin test with probability
greater than 1/4.
Prime *generation* has some important differences from
primality *testing*. What we really want to know is the
chance that the number we generate is composite. If our
procedure is to generate random 512-bit odd integers, and
output the first one that passes a base-2 Fermat test, then
the chance we will output a composite is negligible.
> Is this in fact the case; is there some set of "recommended" bases that
> should be used?
1 Sieve (or trial divide or gcd-test) for small prime
factors; anywhere from the first 50 primes to the first
50000 is fine.
2. Do one base-2 Miller-Rabin (or Fermat) test.
3. Do several random-base Miller-Rabin tests, or a Lucas
test.
In practice, step 2 dominates the run time, since it usually
rejects many candidates.
Alternately, we can generate provable primes in not much
more time, but there's no practical advantage.
--Bryan
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Function other than xor?
Date: Sat, 14 Apr 2001 17:47:54 -0300
Hi mathematicians
Is there a function that create logical relation between to bit-string?
without using any table.
DES is f(010001...) = 010100101..... the size is 64.
I'm looking for a general bijective function
Whatever is the size of the block. I'm mean globally not related bit by
bit.
Not the inverse f -1, not a permutation function.
Sample: f(0100101001) = 0101001010
or f(010) = 011
Has someone created this kind of function?
Thank you for help.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: How to use Dynamic Substitution
Date: Sat, 14 Apr 2001 21:54:29 GMT
On Thu, 12 Apr 2001 00:24:33 +0200, in
<9b2llm$t4l$[EMAIL PROTECTED]>, in sci.crypt "Henrick
Hellstr�m" <[EMAIL PROTECTED]> wrote:
>Disregarding the patent issues, how should DS be applied should one choose
>to use it? It seems as if it, in its basic form, is not a that much stronger
>combiner than XOR.
>
>For example, if XOR is used as a combiner for an OTP, then if Pi is known,
>so is Ki. Hence an attacker who knows Pi and wants to send P'i instead might
>substitute Ci for (P'i XOR Pi XOR Ci). Such attacks are a little bit harder
>if the combiner is DS, but only a little bit. A chosen plain text attack
>will reveal not only the value of Si[Pi] and Si[P'i], but also after an
>average of 16 bytes of cipher text (provided that an 8-bit S-box is used)
>the value of Si[Ki], since it is the first value such that Cj != C'j, i.e.
>the first occurence of error propagation in the cipher text.
Dynamic Substitution is like any tool in that it has both advantages
and disadvantages with respect to a practical alternative. Applying
the tool requires understanding what it is, what it can do, and using
it in the appropriate context.
Dynamic Substitution is intended to solve a particular weakness in the
classic additive stream cipher. The classic approach (from Vernam) is
to combine a Random Number Generator (RNG) "confusion" stream with
plaintext data with exclusive-OR. In such a cipher, the obvious
*intent* is to protect the plaintext, but the obvious *attack* is on
the confusion: if the RNG can be solved or extrapolated, the stream
cipher is broken.
In a real cipher system, it is generally not possible to prevent the
existence and exposure of some amount of known-plaintext (although we
certainly can limit the amount of data ciphered under one key). But
most linear RNG constructions have strength related only to the size
of their internal state, which means a 64-bit RNG might be solved with
only 64 bits of known-plaintext.
When we replace exclusive-OR with Dynamic Substitution, the confusion
stream is *not* immediately revealed by known-plaintext. This
prevents an immediate attack on the RNG state, and so clearly does
represent added strength beyond exclusive-OR. Of course, we are no
more able to quantify that strength than we are able to quantify the
strength of the various unbroken RNG approaches or ciphers themselves.
Having "improved" strength does not imply invulnerability. Nor does
added strength imply that we should be satisfied with a single level
of Dynamic Substitution, any more than Feistel block ciphers rely upon
a single round.
Dynamic Substitution is based on a table, and being somehow able to
expose the contents of that table will reduce its strength to the
expense of the effort to traverse the table. The obvious way to reach
the table contents is to control the input to and monitor the output
from the table. A real Dynamic Substitution design will thus work to
avoid that weakness. Just dropping Dynamic Substitution into a system
and expecting that alone to prevent all possible attacks is simply
unrealistic.
In one real approach, I have used two levels of Dynamic Substitution,
with the second level being a polyalphabetic choice among 16 different
dynamic tables. In this way there is no exposure of both the input
and the output for any one table at any time. That would seem to
avoid some of the problems. See:
http://www.io.com/~ritter/CLO2DESN.HTM#Structure
>Of course, this is only an academic attack provided that the OTP is really
>never reused, but it might be a practical attack against certain types of
>stream ciphers, e.g. synchronized stream ciphers if there is a way to attack
>the method of synchronization.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Function other than xor?
Date: Sat, 14 Apr 2001 17:49:58 -0300
The title is wrong.
Only function because Xor is operation.
Excuse me.
newbie wrote:
>
> Hi mathematicians
>
> Is there a function that create logical relation between to bit-string?
> without using any table.
>
> DES is f(010001...) = 010100101..... the size is 64.
>
> I'm looking for a general bijective function
> Whatever is the size of the block. I'm mean globally not related bit by
> bit.
> Not the inverse f -1, not a permutation function.
>
> Sample: f(0100101001) = 0101001010
> or f(010) = 011
>
> Has someone created this kind of function?
>
> Thank you for help.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Substitution Question
Date: Sat, 14 Apr 2001 21:55:55 GMT
On Fri, 13 Apr 2001 08:22:55 -0700, in
<RREB6.2$[EMAIL PROTECTED]>, in sci.crypt "B. E. Busby"
<[EMAIL PROTECTED]> wrote:
>"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> newbie wrote:
>>
>> > If it was published, give me just one reference. I will be glad to know
>> > it.
>>
>> You published it here in sci.crypt.
>
>Statutory rejection requires written publication.
I think the statement is arguable.
I know that "written publication" is interpreted liberally, because I
have had a *verbal* academic presentation -- in an overseas venue --
upheld by a PTO crypto-group examiner against my application, even
though the printed proceedings did not appear until over a year later.
Maybe I could have fought that, but I expect they know far better than
I what is likely to prevail in court.
Newsgroup publication definitely *is* "written," and one might argue
that anything causing letters to be displayed is "printed." Newsgroup
publication is open to the public, worldwide, and available in
libraries. The only legal problem I see is that the publication date
in an article may not be reliable in a legal sense.
But for dates, archives may exist, and responses to the original
publication also have dates and authors who can testify when they
responded. So the original article logically must have occurred prior
to that time. In this way, the publication date at least potentially
can be bounded in a legal sense, and established in court.
I actually have submitted articles from sci.crypt as prior art in
crypto patent application which was allowed. And sooner or later some
anticipating prior art will be found from a newsgroup archive and used
in court.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "AY" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sat, 14 Apr 2001 23:06:43 +0100
>MS is intentionally placing our right
>to privacy at risk.
There are easier ways for MS to invate the user's privacy than deliberately
implementing a insecure swap file system. In any case I think better
programming _could_ help with the swap file security issues.
>The only discretion one has at this time is to NOT use any leaky MS
>security sieve of an OS.
Hmm....
> X-Mailer: Mozilla 4.7 [en] (Win98; I)
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 22:04:23 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9bagpk$h5e$[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >Question: Does the BM algorithm apply when non consecutive outputs are
> >known?
>
> I don't know. The standard formulation requires 2n bits of consecutive
> known keystream, but I don't know whether their techniques can be extended
> to handle the case where the known keystream bits are not consecutive.
> It's an interesting question....
Wouldn't a secure LFSR just be one where you dump say N bits then output 1
... That way the output picture is incomplete...
My naive instinct says "NO BAD IDEA TOM" but I am not sure... (not sure
about much, which makes me a dork and a amateur!).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sat, 14 Apr 2001 22:06:11 GMT
"AY" <[EMAIL PROTECTED]> wrote in message
news:9bad2r$h88$[EMAIL PROTECTED]...
>
> >MS is intentionally placing our right
> >to privacy at risk.
>
>
> There are easier ways for MS to invate the user's privacy than
deliberately
> implementing a insecure swap file system. In any case I think better
> programming _could_ help with the swap file security issues.
"Secure swap file" is almost an oxymoron. I dunno. A lot of desktop
machines have oodles of ram afaik (mine has 384mb... my bro has +400mb... my
friend has 192mb... etc)... swap files "should" be obsolete.
Tom
------------------------------
** 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
******************************
