Cryptography-Digest Digest #148, Volume #14 Sun, 15 Apr 01 08:13:01 EDT
Contents:
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Concerning US.A.4979832 (Mok-Kong Shen)
borZoi - An Elliptic Curve Cryptography Library ("Anthony Mulcahy")
Re: NSA is funding stegano detection (Mok-Kong Shen)
AES poll (Lars Ramkilde Knudsen)
Re: There Is No Unbreakable Crypto (Mok-Kong Shen)
Re: Dynamic Substitution Question (David Formosa (aka ? the Platypus))
Re: AES poll (Mok-Kong Shen)
Re: Dynamic Substitution Question (David Formosa (aka ? the Platypus))
Re: Comment on SafeBoot's RC5 algorithm (Marc)
----------------------------------------------------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sun, 15 Apr 2001 09:15:47 GMT
Terry Ritter wrote:
>
>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.
By the simple process of ignoring what "source" means.
>>>>>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.
And not two data sources, as the term is used in the patent.
>>>>>>> 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.
What happened here is that you appealed to the wording of
claim 15 since the statement of claim 1 doesn't fit. Yes
any claim counts, but claim 1 with certain wording replaced
by text from claim 15 doesn't count.
>>[...]
>>>>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.
You are pretending the issue is something it is not.
[...]
>>>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?
I work with SSL, TLS and WTLS, so from many sources I'm
aware of their popularity and their use of RC4. Would you
want the addresses of Netscape and Microsoft? I'm not sure
I see the relevance.
>>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.
I can testify to what I wrote, not your misunderstandings.
>>>>>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.
False. If you are going to accuse me of not doing my
homework, you might at least read and follow.
[...]
>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.
That's not what I'm saying. Shuffle doesn't fit, and RC4
doesn't fit for similar reasons.
[...]
>>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.
No, claim one clearly puts the table and the mechanism that
sets its state inside the combiner. The table state
produces the stream at issue, so it does not fit as a
"source" to the combiner. The mechanism you identified is
not even shaped like dynamic substitution.
>>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.
You are only fooling yourself. Do you disagree that the
patent shows "source" is used as usual in the description of
algorithms to mean an input sequence?
>>>"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.
So then the quote is not relevant. We've dealt with the
"source" issue elsewhere.
[...]
>>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.
The patent discloses, or teaches some technique. The patent
also "claims" what is a new invention. You cannot
re-interpret the terms, to make internally produced data a
source. The mechanism you claimed to be dynamic
substitution is not combining two sources or two RGN
sequences; it's generating one PRNG sequence from state.
--Bryan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Concerning US.A.4979832
Date: Sun, 15 Apr 2001 11:37:31 +0200
Terry Ritter wrote:
>
> [EMAIL PROTECTED] (John Savard) wrote:
> >I don't think there's any prior art which anticipates the preferred
> >embodiment.
>
> Again -- and I doubt that anyone could be more clear -- I am unaware
> of any prior art which anticipates the described invention, whether
> limited to the preferred embodiment or not. In particular, I am
> unaware of any prior art which anticipates this particular mechanism
> for combining of two RNG streams.
I think that one confusion has been caused by the text in
the patent concerning combining two streams (stated
without qualifications) so that one would erroneously
understand that the claim were about the 'general' idea
of combinging two streams to produce a presumably better
one, which is however certainly prior art, since e.g.
Wichmann and Hill have combined n (n arbitrary) streams
of PRNG outputs. A particular/specific and new way of
combination that can be shown to be beneficial to crypto
could on the other hand be conform to the purposes
underlying patent laws, i.e. giving protection to inventers.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Anthony Mulcahy" <[EMAIL PROTECTED]>
Subject: borZoi - An Elliptic Curve Cryptography Library
Date: Sun, 15 Apr 2001 19:04:48 +0900
I would like to announce the first public beta release of borZoi, an
elliptic curve cryptography library.
This library is intended to provide developers with an easy means of adding
elliptic curve cryptography support to their applications. It is released
under the GNU General Public License (GPL). The current version number is
0.8.1 and both ECDSA and elliptic curve encryption are functional.
Please see http://www1.kcn.ne.jp/~anthony/software/ for more details.
Anthony Mulcahy
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Sun, 15 Apr 2001 12:25:11 +0200
[EMAIL PROTECTED] wrote:
>
> I'd have thought that detection of otherwise well constructed
> steganography would be based on statistical analysis of the degree of
> entropy or randomness in the data. Any unencrypted image, or other
> file, intended to convey information is by definition not random. So
> GIFs, JPEGs etc are not random. It would be perfectly feasible to
> analyze a huge quantity of such files (ones without hidden messages)
> to establish their statistical properties - in particular the degree
> of randomness. Then one could focus on statistical comparisons of
> files being sent by others with a view to establishing whether there
> is any probability that the degree of randomness is more or less than
> expected. Thus routinely embedding a pseudo-random (encrypted) file
> in an image must marginally bias the degree of randomness of values in
> the data. But, if the message is very small in proportion to the
> container, then probability of detection is reduced. And, if very few
> messages are sent, then probability of detection is also reduced.
I don't think so. You may be able to find some statistical
properties from pictures of a particular artist, just like
style analysis of an author. But the painting of a little
child or a computer generated chaos picture would have quite
other properties.
> On this basis, I suspect that those using steganography in pictures
> should:
>
> 1) use messages that are small relative to the container
> 2) send images containing messages infrequently
> 3) send lots of images which contain no messages
> 4) perhaps, consider ways to salt encrypted messages after encryption
> such that the frequency of bit values is not random, but rather
> reflects the distribution of bits in the original container image, so
> as to leave the statistical properties of bit values in the container
> unvaried once the image is embedded.
The total volume of images sent might be an issue. If two
people exchange daily a number of pictures, that could
under circumstances be suspicious. (On the other hand, a
large number of pictures on a web site, e.g. a porno site,
could evade suspicion and provide anonymity of the receiver.
However, pictures all of a very restricted class might
cause the problem of statistical properties.) Assuming
that no 'standard' statistical properties of pictures
exist (see above) and one sends (in the one-to-one case)
only rather infrequently a picture (painting, photo,
drawing) that correspond well to the accompanying text
and the number of bits embedded is sufficiently small,
I continue to think that detection by the opponent can
be fiarly difficult.
M. K. Shen
------------------------------
From: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Subject: AES poll
Date: Sun, 15 Apr 2001 12:57:22 +0200
Cast your vote on
http://www.ii.uib.no/~larsr/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: There Is No Unbreakable Crypto
Date: Sun, 15 Apr 2001 13:06:08 +0200
David Wagner wrote:
>
> Douglas A. Gwyn wrote:
> >Not long ago we had a thread about what might be required to attain
> >"super-strong" encryption, but it died out, with minor lasting effect
> >only on a couple of Web sites. However it did point up where we need
> >theoretical work in order to attain the goal with confidence. And
> >nothing has indicated that such theoretical work is impossible.
>
> Interesting. I came away with a different conclusion: my take-away was
> that all the theory we need to build super-strong encryption already exists.
>
> See, for instance, my post on the GGM tree-based PRG-doubling scheme:
>
>
>http://groups.google.com/groups?q=super+strong+4n+daw%40*&hl=en&lr=&safe=off&btnG=Google+Search&site=groups
Very dumb question: It seems that your argument hinges
on the block size being larger (double) than the key.
If the key is at least of the size of the block (e.g. AES),
then that line of reasoning wouldn't work, isn't it?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Dynamic Substitution Question
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Apr 2001 11:11:21 GMT
On Thu, 12 Apr 2001 14:03:57 GMT, Trevor L. Jackson, III
<[EMAIL PROTECTED]> wrote:
> newbie wrote:
>
>> Did you compare the result with OTP?
>> Has someone independant of the inventor measure DS and OTP?
>
> What property of the system do you want measured? The throughputs are
> approximately the same, typically being dominated by the IO.
Howabout the leval of infomation leekage?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AES poll
Date: Sun, 15 Apr 2001 13:12:48 +0200
Lars Ramkilde Knudsen wrote:
>
> Cast your vote on
>
> http://www.ii.uib.no/~larsr/
As discussed in a recent thread, the term 'broken'
unfortunately seems to be understood by different
people differently.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Dynamic Substitution Question
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Apr 2001 11:14:40 GMT
On Thu, 12 Apr 2001 14:57:08 GMT, Trevor L. Jackson, III
<[EMAIL PROTECTED]> wrote
[...]
> Given a collection of messages to transform, the DS technique provides two
> benefits over simple, static substitution. First, at the individual message
> level, every character is transformed by a distinct image of the substitution
> table (*), and second, at the collection of messages level, after the first
> character every message is transformed by a distinct sequence of
> tables (*).
Why is this a benifit?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Comment on SafeBoot's RC5 algorithm
Date: 15 Apr 2001 11:46:23 GMT
>If you are using a benchmark that isn't measuring just transfer rate
>you aren't going to get a figure that indicates just the transfer rate.
Well I guess this is the key question. What do we expect when we buy
a drive with 40MB/s, encrypt it with a 400MB/s cipher and run it on a
computer with 1.5GB/s memory throughput, all figures taken from advertisment.
Are we surprised when we measure (say) 5MB/s on a real system, under
real world conditions? Namely reading files from the disk, and especially
files with size and fragmentation equal to those on a typical harddrive?
And if we are surprised, then why? Because we expected more, or possibly
because we expected even less?
_I_ do not believe in 40MB/s drives nor in 400MB/s ciphers. Ask me again
in 3 years or when advertisement departments have re-defined the meaning
of "second" or "MB" (which by the way they did already, once).
------------------------------
** 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
******************************
