Cryptography-Digest Digest #73
Cryptography-Digest Digest #73, Volume #14Wed, 4 Apr 01 03:13:01 EDT Contents: Re: Data dependent arcfour via sbox feedback (Terry Ritter) Re: patent this and patent that (Terry Ritter) From: [EMAIL PROTECTED] (Terry Ritter) Subject: Re: Data dependent arcfour via sbox feedback Date: Wed, 04 Apr 2001 06:17:48 GMT On Wed, 04 Apr 2001 02:08:58 +0200, in [EMAIL PROTECTED], in sci.crypt Mok-Kong Shen [EMAIL PROTECTED] wrote: Terry Ritter wrote: Mok-Kong Shen[EMAIL PROTECTED] wrote: John Savard wrote: Mok-Kong Shen[EMAIL PROTECTED] wrote: Further, as I pointed out in another follow-up, many schemes in Chap. 16 and 17 of Schneier's AC combine two or more pseudo-random streams, i.e. two (or more) confusion sources, to produce a stream that is presumably stronger. i.e. a more-complex confusion result. Are these not in clear and unambiguious conflict with the patent? Dynamic Substitution is a _particular way_ of combining two streams. XORing them together does not conflict with his patent. It is to be noted that xor is also a substitution and, if one utilizes feed back, then the substituion is 'dynamic'. I doubt I would describe that as "dynamic," but in any case it is not Dynamic Substitution as formally described in the patent. Just because the title of the patent is: "Dynamic Substitution Combiner and Extractor," does not mean that it covers any possible thing which is "dynamic" and also some form of "substitution." The coverage is described in the claims, not the title. You are going out of your way to deliberately misrepresent the patent. Your claims about what it says do not make it say that. Like everyone else, you have the opportunity to read the patent and to learn how to interpret patent claims, if that is what you want to do. But since you continue to misrepresent what is there, it seems that what you really want to do is to whine, whine, whine about the unfairness of it all, rather then acquiring the background necessary for understanding. My worry stems on the one hand from your claims of general coverage in previous posts and on the other hand from a diagram on you web page, which in my view seems to cover a quite general feedback scheme. Which diagram, on what page? That's why I wanted to know explicitly whether using feedback as such is or is not violating your patent. Incidentally, feedback is a mechanism that has interested me for some time. (A couple of my humble crypto designs employ feedback.) Well, feedback has long been a very basic part of hardware circuit design (analog, or "linear" design). Most Op Amp (operational amplifier) circuits use extensive negative feedback, often to make the gain effectively independent of the active device, and to reduce distortion. Most oscillator circuits use some form of positive feedback to replace any loss in the frequency-selective section. There is also a concept of "feedforward," often used to cancel distortion without using feedback. Feedback is fairly old (70 years?), very common stuff, and very often treated in the technical literature. With respect to cryptographic feedback, autokey stream ciphers are also quite old. The PK-Zip cipher (from a decade ago?) is a modern example. I don't think we can draw a useful feedback analogy to Dynamic Substitution per se, although the inverse process (the extractor) might be more like it. There is no intent in the Dynamic Substitution patent to control feedback per se. I cannot even imagine trying to get a general patent on feedback now, because it is a widely-understood part of technology; there is massive prior art. But even now, there might be particular ways to control or use feedback which might be patentable. All of our legal systems have problems. But the patent system at least puts the force of law in the hands of even tiny companies. In open competition in a free market, the big guys normally win. I think there is something to be said for an alternative, even if not ideal in many ways. In particular, I think the US government should undertake to prosecute every granted US patent in foreign countries so that the same limitations will apply across the global marketplace. I also think the US government should have a department to help enforce the patent grant. As I see it, the main problem with patents is not that they are too strong and intrusive, but that they are not strong enough. Oh yes, it could certainly impose its laws onto foreign countries and do the said 'prosecutions' through the help of its mighty military forces. The day of the scenario you described may in fact be nigh. Who knows the future for sure? I did not say "impose its law," I said "prosecute . . . in foreign countries"; that would be in their PTO, or the EPO
Cryptography-Digest Digest #73
Cryptography-Digest Digest #73, Volume #13Thu, 2 Nov 00 08:13:00 EST
Contents:
Re: BENNY AND THE MTB? (Tim Tyler)
Re: Crypto Export Restrictions (CiPHER)
Re: ECC choice of field and basis (Nigel Smart)
Re: On introducing non-interoperability (Mok-Kong Shen)
Re: Give it up? (Mok-Kong Shen)
Re: Crypto Export Restrictions ("Dmitry Softman")
Re: Give it up? (Richard Heathfield)
index of coincidence of Spanish/Turkey ([EMAIL PROTECTED])
Re: Give it up? (Tom St Denis)
Re: ECC choice of field and basis (Scott Contini)
Re: Give it up? (Tom St Denis)
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: BENNY AND THE MTB?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 2 Nov 2000 10:11:12 GMT
[EMAIL PROTECTED] wrote:
: "Tim Tyler" [EMAIL PROTECTED] wrote:
: Matt's code takes a message, compresses it, maps the result to
: a 128-bit granular file, encrypts it, and maps the result to
: an 8-bit granular file.
: Actually that clarified the issue [...]
Ah, good - please ignore my last message, then.
: Correct me if I'm wrong, but what matt has done is taken a file,
: compressed it, encrypted it, and (de) compressed it (I'm a little hazy
: on whether the last step should be considered compression or
: decompression).
AFAIK, the last step doesn't really do much in the way of compression
or expansion. It doesn't attempt to compress the statistically random
cyphertext. However it does result in slightly shorter files - simply
because the size of granularity of the files is decreased.
In other words, if you must label this last step as compression or
decompression, the former is likely to be more appropriate.
: I was wrong, this can result in even a 1-bit ciphertext, so an 8-bit
: ciphertext is clearly possible.
The map is *designed* to go to 8-bit files. You could go to a finer
granularity, but at the expense of not producing a neat output file that
can be stored in a typical filing system.
: However I would still consider it proper to call it a 128-bit
: ciphertext, as that should be close to the average length [...]
Hmm. Cyphertexts can be any number of bytes long. Multiples of 128 bits
are not especially common.
: (there will be tiny biases in the ciphertext which can be compressed
: further [...]
That would be suprising. Usually attempts to compress cyphertext result
in slight expansion - not slight compression.
: [...] and there will be encoding in the compression that adds a tiny
: amount of space). [...]
Don't say this - you'll only rub David Scott up the wrong way ;-)
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
--
From: CiPHER [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 10:13:03 GMT
In article [EMAIL PROTECTED],
Anthony Stephen Szopa [EMAIL PROTECTED] wrote:
Anyone who would make such a claim and not support it is clearly a
nasty person.
*waggles fingers* OoooOOOooo! 'Nasty person'! lol
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Nigel Smart [EMAIL PROTECTED]
Subject: Re: ECC choice of field and basis
Date: Thu, 2 Nov 2000 10:39:49 GMT
Scott Contini wrote:
In article Mo%L5.12208$[EMAIL PROTECTED],
Michael Scott [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote in message news:8tpumv$hd9$[EMAIL PROTECTED]...
Hello,
.
1) What are the advantages and disadvantages of choosing GF(2^m) or
GF(p) (and why not GF(p^m) in general)?
Good questions. Generally, and rather surprisingly, GF(p) is significantly
faster in software, not pushed by any commercial interest, much less subject
to patents. GF(2^m) is faster in special hardware, certain interests are
pushing it hard, and is more likely to involve patents. Some restricted
variants of GF(2^m) curves allow fast implementations, but some of these
have been found to be weak (giving the whole field a bad name).
My personal experience is that GF(p) and GF(2^m) are about the same
speed: depending on the operation (public key/private key) and some
other factors which I should not discuss, you may get one faster than
the other but the times (for me) have always been within a factor of 2
of each other. BTW my comparisons were done on a Pentium pro where the
GF(p) implementation had assembly code, but the GF(2^m) implementation
did not since we were unable to improve on the compiler's optimisation
for this case.
I would agree, the field ops in GF(p) are faster but this is compensated
by faster curve ops in GF(2^p).
They are both as good as each other in terms of security as well.
Nigel
--
Dr Nigel P. Smart | Phone: +44 (0)1
Cryptography-Digest Digest #73
Cryptography-Digest Digest #73, Volume #12 Tue, 20 Jun 00 17:13:01 EDT
Contents:
Re: Flattening of frequency distributions (Stefan Schlott)
Re: New Hash Function (David A. Wagner)
URL for The Gold Bug (Re: Classical Crypto Books) ([EMAIL PROTECTED])
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Q: Computing with Gaussian numbers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Linear Feedback Shift Register *with* lock-up? (Ponder)
Re: Is this a HOAX or RSA is REALLY broken?!? (Anton Stiglic)
Re: How RSA SecurID tokens work? (Vin McLellan)
Re: How RSA SecurID tokens work? (Vin McLellan)
Re: Linear Feedback Shift Register *with* lock-up? (Nick Maclaren)
Re: Encryption on missing hard-drives (Paul Rubin)
Re: small subgroups in Blum Blum Shub (Mok-Kong Shen)
Re: Weight of Digital Signatures (Mok-Kong Shen)
Re: Cryptographic voting ("Rick Braddam")
Re: Is this a HOAX or RSA is REALLY broken?!? ("Trevor L. Jackson, III")
Re: Is this a HOAX or RSA is REALLY broken?!? (JCA)
Re: Double Encryption Illegal? (JCA)
Re: small subgroups in Blum Blum Shub (lcs Mixmaster Remailer)
From: [EMAIL PROTECTED] (Stefan Schlott)
Subject: Re: Flattening of frequency distributions
Reply-To: [EMAIL PROTECTED] (Stefan Schlott)
Date: 20 Jun 2000 20:12:27 +0100
On Mon, 19 Jun 2000 20:24:36 +0200,
Mok-Kong Shen [EMAIL PROTECTED] wrote:
That's what the following encryption process is for.
But if a secret key is involved in the flattening process, you have
in effect a multiple encryption.
I did make a distinction between multiple encryption and simply
flattening distributions.
You asked for a way to flatten distributions in natural language,
because exploiting uneven distributions are a classic tool of crypt-
analysis.
Compressing your text before encrypting it will do that. You might
run into trouble with data which cannot be compressed with the codec
in use. Further (as I already mentioned), special care should be given
when storing the data necessary for decompression; when not done
properly, this will lead to known-plaintext attacks.
Are you assuming that the compression algorithm is secret? If not,
and there is no secret key involved, then the opponent can decompress,
so that he is in the same situation as if no compression has been done.
The analysis is more difficult since you cannot exploit distributions
of natural language. But: Yes, anyone can decompress the compressed
text - after decrypting it. As I already said: I thought you wanted to
go for something different than multiple encryption.
Stefan.
--
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: New Hash Function
Date: 20 Jun 2000 11:14:58 -0700
Well, for one, there is an inversion attack with 2^96 complexity,
which is much less than you'd expect for a 192-bit hash. The reason
is that your chaining function can be computed in both the forward
and backwards direction, so you can do a meet-in-the-middle attack.
The fix? Use a Davies-Meyer-like construction, i.e., change
/* perform the rounds */
for (r = 0; r ROUNDS; ) {
F(out, out+3, W[3*r++]); F(out+3, out, W[3*r++]); }
to
for (i=0; i6; i++)
oldout[i] = out[i];
/* perform the rounds */
for (r = 0; r ROUNDS; ) {
F(out, out+3, W[3*r++]); F(out+3, out, W[3*r++]); }
for (i=0; i6; i++)
out[i] += oldout[i];
--
From: [EMAIL PROTECTED]
Subject: URL for The Gold Bug (Re: Classical Crypto Books)
Date: Tue, 20 Jun 2000 18:07:30 GMT
The Gold Bug is also available free online at
http://bygosh.com/Features/062000/goldbug.htm
It is the current featured short fiction on http:/byGosh.com
-- Westcoasting
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (CryptoBook) wrote:
snip
THE GOLD BUG
by Edgar Allen Poe
Published at $13.95.
snip
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Variability of chaining modes of block ciphers
Date: Tue, 20 Jun 2000 20:36:56 +0200
Runu Knips wrote:
Mok-Kong Shen wrote:
The most popular block chaining mode seems to be CBC.
There is also PBC which chains with plaintext blocks.
One can also accumulate the previous blocks for doing the
chaining and use plaintext as well as ciphertext for
chaining. (I used this in one of my own designs.) By
combinatorics this gives 8 variants. Obviously one can
also use modular addition instead of xor and do some
random rotations if one likes. I think that the variability
of chaining modes could be advantageousy exploited such
that the actual chanining mode used in a message has to be
guessed b
Cryptography-Digest Digest #73
Cryptography-Digest Digest #73, Volume #11Tue, 8 Feb 00 15:13:02 EST
Contents:
Compression cannot prevent plaintext recognition (was Re: is signing a (David
Hopwood)
Re: Anti-crack (Mike Rosing)
Re: permission to do crypto research (Xcott Craver)
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("Tony T. Warnock")
Re: Seeking Information on FRACTAL CRYPTOGRAPHY (John Savard)
Re: Anti-crack ("John E. Kuslich http://www.crak.com")
Re: Anti-crack ("Trevor Jackson, III")
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) (John Savard)
Re: Anti-crack ("John E. Kuslich http://www.crak.com")
I'm returning the Dr Dobbs CDROM (Victor Zandy)
Date: Tue, 08 Feb 2000 05:43:29 +
From: David Hopwood [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Compression cannot prevent plaintext recognition (was Re: is signing a
=BEGIN PGP SIGNED MESSAGE=
Tim Tyler wrote:
Anton Stiglic [EMAIL PROTECTED] wrote:
: Tim Tyler wrote:
: Anton Stiglic [EMAIL PROTECTED] wrote:
: : Tim Tyler wrote:
: : A compressor with an accurate model of the data will not just make it more
: : difficult to detect a correct message from an incorrect one, it can make
: : it *massively* more difficult.
:
: : Not true at all. If a compressor is used, the attacker will probably have
: : his hands on it, it won't complicate stuff much for him at all!
: : This is what people tend to forget...
[...]
: Compression *can* make finding halting criteria harder.
: No, it does not make it any harder. The attacker just tries to decrypt
: to some plaintext p', then decompresses that, call the result p, and
: checks if p has the headeras he is looking for.
If the compression is correctly and accurately targetted at the datatype
it is compressing, there will be zero files which lack the "header" in
question.
Who said that all files are of a single datatype? Many, perhaps most
encryption systems do not just work on a single datatype.
If all files have the header, the compressor can strip it out, and the
decompressor can insert it again at the other end.
If not all files have the header, it's not going to work very well
as a halting criterion.
On the contrary, the compressor and decompressor have to work for all
files that *could* be transmitted, whereas the attacker only has to
implement a halting criterion that works for the particular files
that *are* transmitted. For example, the attack might be targetted at
a particular user who only encrypts files of a certain type.
Take email, for example. Here are some characteristics common to my
outgoing email messages:
- the headers include information about my mail reader, return address,
the location of my ISP, my company name, and so on, most of which is
constant.
- they are written in English, but with a particular word distribution
atypical of most English text (e.g. words relating to cryptography
or computer security occur disproportionately often).
- most sentences would pass a simple grammar check that doesn't attempt
to assign any meaning to words.
- quoting is always done using " ".
- there is exactly one space separating a full stop from the next
sentence.
- punctuation goes outside rather than inside quotation marks,
"like this".
- the lengths at which lines are wrapped are not consistent (as they
would be with automatic line wrapping).
- there are often lists like this one in which each item is introduced
by "-" indented by exactly one space.
- they have the same plaintext .sig.
- they are PGP signed with my key.
An attacker can choose *any* characteristic that distinguishes a real
message from a random output of decompression, and the compression
algorithm can't possibly remove all of them. You can go to as much
trouble as you like tailoring the compression to particular message types,
but if the attacker knows anything at all about the distribution of
expected messages, he/she can probably find a relatively simple
distinguishing feature that you missed. Partly this is because the
redundancy is only clear when looking "across" messages, while the
compressor can only work on individual messages.
Much the same is true for any other plaintext characteristic - with good
enough compression, *all* possible decrypted files will decompress to
plausible-looking plaintext files.
You're wrong, for three main reasons:
- the compressor/decompressor has to actually implementable, within the
current state of the art, and take a reasonable amount of time and memory.
The problem of creating plausible-looking random messages (which is
strictly easier than the problem of creating an optimal compressor
for messages with the same distribution) is no
Cryptography-Digest Digest #73
Cryptography-Digest Digest #73, Volume #9Fri, 12 Feb 99 07:13:03 EST
Contents:
Re: block ciphers
Re: My comments on Intel's Processor ID Number (Gareth Williams)
Re: On a Method of Session Key Generation (revised) (wtshaw)
shuffling hexits (wtshaw)
Tell-Tale DES Byte-Length Encoding (TONY BARTOLETTI)
Factoring Complex Numbers ("Wm. Toldt")
Re: *.EXE files Encryption ("Greg Wright")
Re: Tell-Tale DES Byte-Length Encoding ([EMAIL PROTECTED])
Re: What is left to invent? (TONY BARTOLETTI)
Re: RNG Product Feature Poll ("Trevor Jackson, III")
Re: Factoring Complex Numbers ("Lassi Hippeläinen")
From: [EMAIL PROTECTED] ()
Subject: Re: block ciphers
Date: 12 Feb 99 05:45:03 GMT
Vonnegut ([EMAIL PROTECTED]) wrote:
: Ok, given a cipher w/ block length of n, the odds are pretty good, i.e.
: (n-1)/n that the last bit in the last block is a null. Could this be
: exploited in some way to reveal a part of the key, or is it standard to use
: some character other than an ASCII 0 for the nulls to fill the last block.
: I reallly have no level of experience in this stuff, but I thought I'd ask.
There were standard ways of dealing with this in older ciphers, such as
bisection. With today's ciphers, where a computer does everything before
you see the message, a slightly more elaborate scheme is needed, but it
can still be done.
However, modern block ciphers are strong enough to be impervious even to
chosen-plaintext attacks, and thus the risk of a known-plaintext attack is
not generally considered a concern.
One can either include a length code in the message, and fill with random
bits, or pad with 1 and *always* add the 1, even if it means
creating an extra block, the first being a safe way, the second an unsafe
way, of unambiguously indicating the message length in bits. (The length
code, of course, only needs to give the number of bits in the _last
block_). So there are many alternatives, these two being only examples.
John Savard
--
From: Gareth Williams [EMAIL PROTECTED]
Subject: Re: My comments on Intel's Processor ID Number
Date: Fri, 29 Jan 1999 08:35:09 +
Bruce Schneier wrote:
I wrote a column on Intel's Processor ID number for ZDNet. You can
read it at:
http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
see also Paul Rubin's thread 'Some more technical info on Pentium III
serial number'
which discusses this article:
http://www.eet.com/story/OEG19990127S0011
--
Gareth Williams [EMAIL PROTECTED]
** DGW Software Consultants LTD ***
* Montrose, Ledbury Rd, Ross-on-Wye, HR9 7BE, UK *
* Tel/Fax 01989 563704 *
***
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On a Method of Session Key Generation (revised)
Date: Thu, 11 Feb 1999 22:42:36 -0600
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
The only measure is one of confidence, that the results cannot be
anticipated to some degree, and that depends too much on knowledge of the
method. The obscurity of resultant series depends on its
irreproducability by physical means, or by bulk of data in its initial
state, seeds and otherwise.
I do not understand what you have just said, so rather than adding to
the confusion by trying to second-guess what you might have meant, I
will ask you to clarify that statement.
OK, confidence is a statistical measure of how sure you are. In some
areas of science, 0.05 level might be OK, which means you are 95% sure
your results are OK. It has lots to do with sampling techniques. When
you say crypto-grade, it should be defined in similiar form, like 0.001.
An error range should also be specified.
Or, did you mean you needed explanation on the second part? I allude to
an OTP and a pRNG in the same way, our wanting to make the series produced
as little likely to be reproduced by some means as possible. If a pRNG is
sufficiently obscure, then an OTP is not necessary. Consider that a pRNG
can be very complex, its initial state including many variables.
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
Most if not all politicians are included in the criminal class in some
fashion. The term "honest politician" is an oxymoron of the first
order, as history has demonstrated so clearly.
Be careful, most people have done criminal things, knowingly, or not. A
criminal is only one who has been formally found guilty of a certain type
of offense. This is where some politicians mess up. To go from place to
place and preemptively call someone a criminal without a conviction to
back it up other than within a
