Cryptography-Digest Digest #85, Volume #9        Wed, 17 Feb 99 05:13:04 EST

Contents:
  Re: Help! Cryptosystem needed. ("Peter Flodin")
  Re: encryption debate (DM Lanza)
  Re: encryption debate (DM Lanza)
  Re: Block ciphers vs Stream Ciphers
  Re: Web Site Problems, Quadibloc III
  Re: Barcodes
  Protecting Against Replay Attacks With Nonrandom IV
  Re: Would this PRNG work?
  Re: Block ciphers vs Stream Ciphers ("Douglas A. Gwyn")
  Re: True Randomness ("Douglas A. Gwyn")
  More Security for Single-DES?
  Re: Really lousy random numbers ("Douglas A. Gwyn")
  Re: some hash questions (Vladimir Beker)
  Re: Protecting Against Replay Attacks With Nonrandom IV (Terry Ritter)
  Re: Block ciphers vs Stream Ciphers ("Douglas A. Gwyn")
  Re: encryption debate ("Douglas A. Gwyn")
  Re: Privacy, Traps and Frozen Hell ("Douglas A. Gwyn")
  Re: Help! Cryptosystem needed. ("Douglas A. Gwyn")
  Re: More Security for Single-DES? (Terry Ritter)

----------------------------------------------------------------------------

From: "Peter Flodin" <[EMAIL PROTECTED]>
Subject: Re: Help! Cryptosystem needed.
Date: Wed, 17 Feb 1999 13:10:57 +1100

> No rumors, sure they can do it.  Granted, nobody knows NSA�s
>real budget... but it surely is larger than $250.000!


Yes, NSA's budget is closer to $3,500 million per year.

The CIA, the Defense Intelligence Agency, the NSA and military R&D have a
budget of at least $30,000 million, which is greater than what the US spends
on education.





------------------------------

Date: Wed, 17 Feb 1999 00:35:53 -0500
From: DM Lanza <[EMAIL PROTECTED]>
Subject: Re: encryption debate

R. Knauer wrote:

> On Tue, 16 Feb 1999 16:43:24 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >> Amendment X grants unenumerated rights to the STATES.  I believe
> >> you mean to refer to Amendment IX.  Unless my Anheuser's Disease
> >> is affecting my memory.
>
> >This is an error.  The phrase is the states or the people.  Note that
> >this is one of the keys to the proper interpretation of some of the
> >enumerated rights in which the term "the people" appears.
>
> Some? Why not ALL?
>
> There is not one use of the term "The People" that could ever be
> misinterpretated to mean the several States.

Some indicates that only some of the enumerated rights have been distorted
by interpreting "the people"as a reference to government as representatite
of the people "as a whole" instead of as individual persons.

All the liguistic and constitutional scholars who have examined the
terminology usage of the Bill of Rights has concluded that "the people"
means the people not the government(s).  The Xth amendment is one of the
cases where this interpretation is glaring.

>
>
> >Clearly "the people" is not a synonym for the states.
>
> The Founding Fathers knew enough English to know what they meant by
> the use of two completely distinct terms: The People and The States.
> There is no possible confusion, unless someone deliberately tries to
> introduce a bogus misinterpretation.
>
> "The People" means the people, pure and simple, not the State. This is
> further clarified in the writings of that era. Nowhere do the framers
> of the Constitution once mean anything different from the conventional
> meaning of the term "The People".
>
> It's the marxist organizations trying to subvert our Constitution that
> attempt to foist off such ridiculous misinterpretations, and then only
> where it suits them.

It is not only the marxists, but the <pick-a-term>ists who are willing to
distort reality to fit their preconceptions.  Belief has always interfered
with Truth.  Always will.


------------------------------

Date: Wed, 17 Feb 1999 00:38:57 -0500
From: DM Lanza <[EMAIL PROTECTED]>
Subject: Re: encryption debate

Michael Sierchio wrote:

> On Tue, 16 Feb 1999 16:43:24 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >> Amendment X grants unenumerated rights to the STATES.  I believe
> >> you mean to refer to Amendment IX.
>
> >This is an error.  The phrase is the states or the people.  Note that
> >this is one of the keys to the proper interpretation of some of the
> >enumerated rights in which the term "the people" appears.
>
> Amendment IX refers to RIGHTS of the people.  Amendment X says that POWERS
> not delegated to the United States are reserved to the respective
> states or the people.  Amendment IX is the relevant one when discussing
> "enumerated" vs. implicit rights.

On rights v. powers you are, of course, correct.  On your initial statement
"Amendment X grants unenumerated rights to the STATES" you are wrong because
you have truncated the statement, butchering it in the process.  There is
neither mercy nor appeal for this kind of (ahem) error.



------------------------------

From: [EMAIL PROTECTED] ()
Subject: Re: Block ciphers vs Stream Ciphers
Date: 17 Feb 99 07:28:07 GMT

fungus ([EMAIL PROTECTED]) wrote:
: In practice, stream ciphers have slightly more demanding key
: requirements - you can never use the same key twice.

Although I'm kicking myself for not mentioning this difference between
stream and block ciphers, I don't quite agree with what you've said, since
usually, when employing a block cipher, one does so in CBC mode - hence,
making the key requirements exactly the same, since CBC mode requires an
IV.

Yet, it is true that in some sense the block cipher has simpler key
requirements, since a stream cipher cannot be secure without an IV, yet a
block cipher can offer quite a bit of security even when used in ECB mode.

John Savard

------------------------------

From: [EMAIL PROTECTED] ()
Subject: Re: Web Site Problems, Quadibloc III
Date: 17 Feb 99 07:40:03 GMT

[EMAIL PROTECTED] wrote:
: Notwithstanding that, it contains the up-to-date version of my site.

The Freenet site has had the Quadibloc description removed to make space
for using it as a staging area for some material on pentagonal
tesselations now moved to the Xoom site.

Also, I found three pages that had <p> instead of </p> at the end of
paragraphs. This typo causes Cello 1.01a to hang when attempting to
display the page, and has been fixed on those three pages.

John Savard

------------------------------

From: [EMAIL PROTECTED] ()
Subject: Re: Barcodes
Date: 17 Feb 99 07:45:32 GMT

Vicky ([EMAIL PROTECTED]) wrote:
: I knew this already, but what I want to know is how barcodes are coded.
: There seem to be two flavours, 8 digit and 13 digit, and I'm intrigued to
: find out what the algorithm is.  I'm sure I used to know, but I've
: forgotten.  Hopefully it's not quite as complicated as the lovely
: VideoPlus+ algorithm.

There are a lot of different bar code formats, but if you're referring to
UPC codes only, there was an excellent description of them in a Motorola
microprocessor design manual.

Essentially, a 10 digit UPC barcode consists of the following elements:

1) Two vertical bars (1010)

2) The seven-unit codes for the first five digits

3) Two vertical bars (01010)

4) The _inverted_ seven-unit codes for the second five digits

5) Two vertical bars (0101)

So the main unusual thing about them is the fact that the codes are
inverted black-for-white in the second half; this makes it easier for
scanners to recognize an upside-down code (all the codes have the same
parity).

Hopefully, this is enough detail to get you started.

John Savard

------------------------------

From: [EMAIL PROTECTED] ()
Subject: Protecting Against Replay Attacks With Nonrandom IV
Date: 17 Feb 99 07:36:22 GMT

Usually, CBC mode involves generating an IV randomly.

However, the IV isn't encrypted, since for the remaining blocks of the
message, the (visible) ciphertext performs the same function as the IV did
for the first block.

Hence, a random IV isn't strictly required for security; it is just random
to easily ensure that one doesn't always use the same IV - so that one
gains the intended security advantage, which is that identical messages
won't produce identical ciphertexts. CBC mode doesn't produce any other
gain in security; a DES cracker, armed with known plaintext, can handle
any of the original basic block cipher modes with equal ease.

Hence, it appears to me that the following is safe: use, for CBC mode, an
IV composed of a recipient ID and a timestamp. This would prevent replay
attacks _directly_, and would not require using randomness to produce the
IV. This is an advantage, since:

- true randomness is difficult to obtain on computers not equipped with
Pentium III chips, and

- if a PRNG, even a very good one, is used to fill in the breach,
generating visible IV values and secret session keys with the same PRNG
is, at least in theory, a point of vulnerability.

John Savard

------------------------------

From: [EMAIL PROTECTED] ()
Subject: Re: Would this PRNG work?
Date: 17 Feb 99 07:53:06 GMT

[EMAIL PROTECTED] wrote:
: Please comment. Thank you

This is called the "counter mode" of a block cipher, and is considered to
be secure. However, it does depend on the block cipher not having some
structural weakness that might become apparent later, which is perhaps why
only output feedback mode, and not counter mode, of DES was originally
proposed as a way of using DES as a stream cipher.

But that has its own problems: there is a remote chance of short cycles.

I've proposed combining OFB and counter mode, by using as input to the
next block cipher cycle the previous output XOR a counter value. I admit -
as someone pointed out - that no real *security* is gained, since a DES
cracker can attack that with known plaintext as easily as any of the other
basic modes. But it takes care of both (highly remote) additional worries
about the two modes in their original form: there is no danger of short
cycles, and large stretches of consecutive inputs to the block cipher are
not used.

John Savard

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Block ciphers vs Stream Ciphers
Date: Wed, 17 Feb 1999 08:19:54 GMT

Gustavo wrote:
> It seems that the cryptographic community is
> interested almost only in block ciphers and not
> in stream ciphers.

That depends on which "cryptographic community" you hang out with.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness
Date: Wed, 17 Feb 1999 08:23:55 GMT

"R. Knauer" wrote:
> On Tue, 16 Feb 1999 05:17:32 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >NSA cryptographers are aware that coin flipping is not perfectly
> >random, and have tools that can detect that.
> All finite sequences are at best pseudo-random, that is, they can be
> tested by pseuo-random statistical tests - but that does not make them
> truly random. It is the generation process that is either truly random
> or not, and that cannot be determined algorithmically from finite
> outputs.
> ... [etc.] ...

That misses my point (as well as being wrong anyway).
Coin flipping is not even asymptotically random.
It has nothing to do with algorithmic complexity etc.

------------------------------

From: [EMAIL PROTECTED] ()
Subject: More Security for Single-DES?
Date: 17 Feb 99 08:06:27 GMT

Here is a description of a block cipher mode for DES that appears to
increase security at no significant computational cost.

Generate a 64-bit random value, call it T.

Encipher it using K1, and transmit the result.

For every block of the message, first XOR the plaintext block with T, then
encrypt it using K2 and transmit it, then increment T.

However, it can be attacked in 2^56 steps: given two consecutive blocks of
known plaintext, decrypt with every possible key until the XOR between the
results and the plaintext differs by one in the right direction.

If instead of incrementing T, we add T2 to it, also encrypted and
transmitted as an IV, then we need to use three blocks of known plaintext,
and search for a linear relationship.

It seems one can't stop short of using T as the key to a real stream
cipher.

But then I realize what I'm doing wrong, and suddenly this "new DES mode"
becomes something that has already been invented, more or less.

If we XOR the current value of T to the input and the output of DES with
K2, then we are essentially making use of the idea behind DESX. And then a
brute-force search on K2 won't be possible where T (or K1) is unknown.
Except for an extra key setup, this looks like a way of obtaining 112-bit
(Triple DES) security, not at double-DES speeds, but at single-DES speeds.

John Savard

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Really lousy random numbers
Date: Wed, 17 Feb 1999 08:32:07 GMT

"R. Knauer" wrote:
> On Tue, 16 Feb 1999 05:33:13 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >I don't know why you call this a "TRNG", but if the signal without the
> >sinusoidal perturbation asymptotically passes all statistical tests for
> >randomness, so will the perturbed signal you described.
> What do you mean by "asymptotically passes all statistical tests for
> randomness"?

Just what I said!

> For one thing, statistical tests are procedures for determining
> pseudo-randomness. There are no effective procedural tests for true
> randomness.

That's incorrect.  Statistical tests generally test the relative
likelihood of competing hypotheses, or the absolute likelihood of
an observed dataset for some source model.  It is possible with a
simple test to put an upper bound on the truth value for the
hypothesis that the data was generated in accordance with some
specified random-source model.  For example, systematic bias can
be detected (with a certain specific degree of certainty).

> >The real weakness in such a scheme is that the key has to be somehow
> >transmitted to the intended recipient, and *that* might be intercepted.
> That is not an analytical weakness.

It is if you're analyzing the entire cryptographic system,
and not some meaningless academic exercise.

------------------------------

Date: Wed, 17 Feb 1999 10:36:52 +0200
From: Vladimir Beker <[EMAIL PROTECTED]>
Subject: Re: some hash questions

I really cannot understand the reason for such rude tone from both sides.
Our company, which has a lot of very clever people except me :-)  stopped to
use VB, but I think it is mostly related to the kind of applications we
write than to any other reason. As for me, the magic of C is that you can do
virtually anything on it, including things that you definitely cannot do on
VB. Of course there is a price: some kinds of applications is just cheaper
to write by using other tools. So what we are talking about?
Excuse me my bad English. Well, usually I'm not asking for excusion, but I'm
just afraid to get one more ha-ha-ha in this thread.
Vladimir


Vektor wrote:

> [EMAIL PROTECTED] wrote:
> >
> > VB is a toy language. I don't know any intelligent people who haven't
> > stopped using BASIC at the onset of puberty.
>
> hahahaha...thats funny. You obviously dont know that many people with an
> IQ over 100, and I doubt you've hit puberty yet.
>
> just because you dont understand something doesnt mean its 'a toy
> language'.
>
> I was around when C was a 'toy language', and the 'intelligent people'
> were using assembly. anything higher level than assembly was considered
> a 'toy language'. I stood by C then, just like i stand by VB now.
>
> keep your narrow minded, ignorant comments to yourself, kid.
> This is sci.crypt, not inbred.C.programmers.
>
> -Alex


------------------------------

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Protecting Against Replay Attacks With Nonrandom IV
Date: Wed, 17 Feb 1999 08:33:44 GMT


On 17 Feb 99 07:36:22 GMT, in <[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] () wrote:

>Usually, CBC mode involves generating an IV randomly.
>
>However, the IV isn't encrypted, since for the remaining blocks of the
>message, the (visible) ciphertext performs the same function as the IV did
>for the first block.

Sometimes the IV *is* encrypted.  This prevents The Opponent from
intercepting ciphertext and changing the IV, which then changes the
first block of deciphered plaintext.  So if the IV is not protected,
and if the overall plaintext is not error-checked or validated, this
is a way to change the first block from a known value to anything else
at will.  Note that overall CBC error-checking, if used, will not
detect these changes.  

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM



------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Block ciphers vs Stream Ciphers
Date: Wed, 17 Feb 1999 08:36:44 GMT

Patrick Juola wrote:
> A sufficiently cunning adversary could change a few bytes
> and produce ...

That's not a generic deficiency in stream cipher systems, any more
than replay attack is a generic deficiency in block cipher systems.
Any properly designed cryptographic system will take into account
such simple vulnerabilities.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: encryption debate
Date: Wed, 17 Feb 1999 08:39:19 GMT

"R. Knauer" wrote:
> There is no "Right To Privacy" in common law. There is only the right
> to be free from unreasonable searches and seizures.
> Check out the US Constitution if you do not believe me.

The Constitution does not specify anything in "common law";
they're essentially complementary.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Privacy, Traps and Frozen Hell
Date: Wed, 17 Feb 1999 08:50:44 GMT

[EMAIL PROTECTED] wrote:
> The ...  protocol has only 56-bits of shared-secret key -- but it has the
> look-and-feel of 70-bits (for example, could be more) to any attacker.

No, only to an unsophisticated attacker.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Help! Cryptosystem needed.
Date: Wed, 17 Feb 1999 08:53:08 GMT

Peter Flodin wrote:
> The CIA, the Defense Intelligence Agency, the NSA and military R&D have a
> budget of at least $30,000 million, which is greater than what the US spends
> on education.

If so, it's only because we get so much more for our money from our
Defense establishment than from our woeful public school system.

------------------------------

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: More Security for Single-DES?
Date: Wed, 17 Feb 1999 08:47:10 GMT


On 17 Feb 99 08:06:27 GMT, in <[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] () wrote:

>[...]
>If we XOR the current value of T to the input and the output of DES with
>K2, then we are essentially making use of the idea behind DESX. And then a
>brute-force search on K2 won't be possible where T (or K1) is unknown.
>Except for an extra key setup, this looks like a way of obtaining 112-bit
>(Triple DES) security, not at double-DES speeds, but at single-DES speeds.

That is the claim for DESX.  But DESX is fairly well known, and has
been an option for years.  So why are the bankers going to Triple-DES
instead of DESX?  I *know* they hate tripling their encryption
overhead....  

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM



------------------------------


** 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
******************************

Reply via email to