Cryptography-Digest Digest #978, Volume #11       Thu, 8 Jun 00 17:13:01 EDT

Contents:
  Re: equation involving xor and mod 2^32 operations (Bill Daly)
  Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher)) (tomstd)
  Re: Some dumb questions (William Rowden)
  Re: Retail distributors of DES chips? ([EMAIL PROTECTED])
  Re: Cryptographic voting (Lynn Killingbeck)
  Re: DH-Key Exchange Questions. ([EMAIL PROTECTED])
  Re: Extending the size of polyalphabetic substitution tables 
([EMAIL PROTECTED])
  Re: Cryptographic voting (Greg)
  Re: Cryptographic voting (Greg)
  Re: DES question ("Paul Pires")
  Re: software protection schemes (Vernon Schryver)
  Re: Random IV Generation ([EMAIL PROTECTED])
  Re: Cryptographic voting (Greg)
  PGP Self-Decrypt (AllanW)
  Re: Extending the size of polyalphabetic substitution tables (Mok-Kong Shen)
  Re: Some dumb questions (Mok-Kong Shen)

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

From: Bill Daly <[EMAIL PROTECTED]>
Subject: Re: equation involving xor and mod 2^32 operations
Date: Thu, 08 Jun 2000 19:06:50 GMT

In article <[EMAIL PROTECTED]>,
  Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Can someone help me out with the following
> problem.
> I have an equation
>   (a + x) xor (b + x)
> where + is the add mod 2^32 operator and
> xor is the xor operator on bit representation.
> a and b are known, x is the unknown.
> How do I solve such a problem?
> Even better, how do I generally solve a system
> of n equations, containing n variables, in a system
> that has two different operators such as xor and
> addition mod 2^32.
>
> Thanks .
>
> Newbie.
>

You can find all solutions of (a+x)xor(b+x) = c by the following
recursive procedure.

1. If a and b are both even, say a = 2a' and b = 2b', then c must be
even, say c = 2c'. For each solution x' of (a'+x')xor(b'+x') = c', x =
2x' and x = 2x'+1 are solutions of the original equation.

2. If a and b are both odd, say a = 2a'+1 and b = 2b'+1, then c must be
even, say c = 2c'. For each solution x' of (a'+x')xor(b'+x') = c', x =
2x' and x = 2x'-1 are solutions of the original equation.

3. If a and b have opposite parity, say a = 2a' and b = 2b'+1, then c
must be odd, say c = 2c'+1. For each solution x' of (a'+x')xor(b'+x') =
c', x = 2x' is a solution of the original equation, and for each
solution x' of (a'+x')xor(b'+1+x') = c', x = 2x'+1 is a solution of the
original equation.

If you want only one solution, the following C code will do the trick:

  // assuming an unsigned long is 32 bits
  #define ulong unsigned long
  int solve(ulong a, ulong b, ulong c, ulong *x) {
    // returns 1 if an answer is found, with the result in *x
    // or 0 if an answer is not found
    if (a == b) {
      *x = 0; // actually any value will do
      return 1;
    }
    if (a&1) {
      // a is odd
      if (b&1) {
        // a and b are both odd
        if (c&1) return 0; // c has the wrong parity
        if (solve(a>>1, b>>1, c>>1, x) {
          *x += *x; // 2*(*x) is an answer
          return 1;
        } else return 0; // no answer
      } else {
        // a is odd and b is even
        if ((c&1) == 0) return 0; // c has the wrong parity
        if (solve(a>>1, b>>1, c>>1, x) {
          *x += *x; // 2*(*x) is an answer
          return 1;
        } else if (solve((a+1)>>1, b>>1, c>>1, x) {
          *x += *x+1; // 2*(*x)+1 is an answer
          return 1;
        } else return 0; // no answer
      }
    } else {
      // a is even
      if (b&1) {
        // a is even and b is odd
        if ((c&1) == 0) return 0; // c has the wrong parity
        if (solve(a>>1, b>>1, c>>1, x) {
          *x += *x; // 2*(*x) is an answer
          return 1;
        } else if (solve(a>>1, (b+1)>>1, c>>1, x) {
          *x += *x+1; // 2*(*x)+1 is an answer
          return 1;
        } else return 0; // no answer
      } else {
        // a and b are both even
        if (c&1) return 0; // c has the wrong parity
        if (solve(a>>1, b>>1, c>>1, x) {
          *x += *x; // 2*(*x) is an answer
          return 1;
        } else return 0; // no answer
      }
    }
  }


Regards,

Bill


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Subject: Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher))
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 12:22:40 -0700

In article <8holf2$90j$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>
>
>> You can't just throw sboxes at a cipher and make it secure...
>
>eh?
>
>I agree that 'throwing sboxes' at the cipher isn't the ideal
way to
>create a cipher. But in this case, its almost certainly going to
>improve the security of the cipher.
>
>If i'm correct, your attack depends souly on the fact his
cipher is
>just too linear, an s-box is a good non-linear step to include.
>
>Is there any reason it wouldn't be more secure?

Depends on how the sboxes are made, used, etc... If you had say
four parallel sboxes, and the strong linear trait was 2^-3, you
only need 64 plaintexts to identify the keyed-sbox from random.
By keying I assume you have a key before it and some other
steps...

Even still after 5 rounds of this, you have 2^(-3)(5) which is
only 2^-15 and requires 2^30 plaintexts to exploit (at the
most)....

This of course is very general....

Tom


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

From: [EMAIL PROTECTED] (William Rowden)
Subject: Re: Some dumb questions
Date: 8 Jun 2000 19:34:02 GMT

In article <[EMAIL PROTECTED]>, Jim Gillogly  <[EMAIL PROTECTED]> wrote:
> Mok-Kong Shen wrote:
> > 2. If an ideal OTP is misused, in that it is used a small
> >    number n of times, how is one going to attack, if
> >    absolutely no known plaintext is available?
> 
> Going back to the original question (informed by a later message that
> assumes the underlying frequencies of the plaintext are known), I did
> a little example.  I took the first n=10 sentences of Pride and Prejudice
> that are at least 15 characters long, and pulled out the 15th character
> of each,

This creates a sample from an English distribution, without any
English n-grams.  Is that your intent?

> then XORed those characters with a randomly selected key.

The randomly selected key was 10 characters (or 80 bits) long?

> The ciphertext is: 0f 5a 1f 16 1f 1f 14 5a 1b 5a
>
> Now look at all possible values of the key.

This is a brute force solution.  Doesn't each additional character in
the message increase your keyspace by 2**8 (or 2**6 if you limit keys
to letters, numbers, and some punctuation)?  I predict computational
infeasibility.

> For example, decrypting that slice with 0x00 to 0x09 gives:
>
> 00: 0f Z 1f  16  1f  1f  14 Z 1b Z
> 01: 0e [ 1e  17  1e  1e  15 [ 1a [

It appears this is decrypting each character with the same value.  I
don't understand what we learn from this.  Wouldn't this be only a
small portion of the entire keyspace?  The keyspace would be large for
long messages.  This is true even considering that since the "key" in
the "TTP" is the other message (because one can remove the effect of
the key on the two ciphertexts, e.g., by XORing them) it therefore may
have fewer possible characters (say, 64 values per character, rather
than 256).

> 7a:u eleen a 
[snip]
> Of these, 0x7a is the obvious winner

If we search the entire keyspace, aren't there many more candidates?

It seems to me that the XOR of two ciphertexts encrypted with the same
random key is equivalent to transposed plaintext encrypted with a
cryptographically weak pseudorandom number generator.  (I'm continuing
with the assumption that we know frequencies for single characters but
a transposition has changed the frequencies of any larger blocks.)
The real "TTP" key has been eliminated from the combination, and the
resultant "key" has the frequencies of the underlying language.  What
are the attacks on this type of cipher, considering that it is
preceded by transposition?
-- 
    -William
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB  DA28 379D 47DB 599E 0B1A

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

From: [EMAIL PROTECTED]
Subject: Re: Retail distributors of DES chips?
Date: Thu, 08 Jun 2000 19:31:03 GMT

In article <8hh379$k4h$[EMAIL PROTECTED]>,
  zapzing <[EMAIL PROTECTED]> wrote:

> Well, not exactly. At least, that's what I'm hoping.
> For the system I'm working on, the computer would
> basically have an "encrypted hard drive" which
> would mean that there would be hardware encryption
> between the RAM, Processor, etc. and the HD and/or
> floppy drive. Basically, the RAM, CPU, etc. is
> "inside" and the HD and floppy are "outside". It
> works if there is no possible residue left in RAM.
> I don't like having to assume that, but there is
> no choice.

The good people at OpenBSD.org are working on a way of making their swap
area encrypted so that RAM contents exist in plaintext only in RAM and
in the CPU. There are also several projects dealing with encrypted
filesystems that work with Linux. Maybe you could mix the OpenBSD
encrypted swap with the linux encrypted filesystem to get basically what
you are wanting, but without dealing with hardware. It could be a lot
cheaper.

> Perhaps there is something that could be done after
> the computer is turned off, to get rid of any
> information that might be lingering in RAM.
> like powering it up on and off several times.
> Perhaps with lower than recommended supply voltage.
> (Does anyone know anything about that?)

Well, if you have access to the OS source, you could have it malloc()
many many blocks of RAM and fill the contents with prng output, maybe
several times over depending on how paranoid you are.

As a simple rc.shutdown script, I wonder how far one could get with a
simple: dd if=/dev/random of=/dev/mem bs=1024k count=256

? It might not be pretty... but it might also work. :)


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Lynn Killingbeck <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Thu, 08 Jun 2000 14:51:48 -0500

Greg wrote:
> 
> (snip)
>
> First, the law states that you cannot force a person to present
> identificaiton at the booth- that is, you may not be able to force the
> voter to give you a "U".
> 
> Second, those in power want a corruptable system that they can control.
> 
> (snip)
>

Really? Where? Oh, and does it have the side-clause that such failure to
provide identification means that you do _not_ get to vote? As you state
it, a single person could just wander among polling places, claiming to
be someone he/she/it is not at each, and demanding to vote at each one
- and, in the process, depriving the rightful bearer of that name from
voting! Why, the next thing I know, you're going to tell me tales about
the dead voting; or, part of the same old-time strategy, the winner is
whomever can report their totals last, if the vote is at all close!

I don't have to present my voter registration card, but, without it, do
have to present some other official form of identification (typically a
photo ID such as driver's license).

Lynn Killingbeck

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

From: [EMAIL PROTECTED]
Subject: Re: DH-Key Exchange Questions.
Date: Thu, 08 Jun 2000 19:44:54 GMT

In article <8hm0kp$9tn$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:

> right I'm doing something wrong - using VBScript. I just wondered if I
> could get away with a prime number of 71 ... well at least I now know.

It depends on your needs. If you need to secure something from your next
door neighbor, 71 will serve nicely, unless your next door neighbor
happens to be decent at math. (Undergraduate level math majors will find
no problems breaking this open. :)

On the other hand, if you are trying to secure industrial secrets that
could be worth several million dollars to a competitor, then primes 768
bits and larger are to be suggested. :)


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED]
Subject: Re: Extending the size of polyalphabetic substitution tables
Date: Thu, 08 Jun 2000 19:58:21 GMT

MK, I suppose it depends upon your needs. If you are mainly interested
in methods of historical ciphers, sure, these methods will be nice
extensions of previous ciphers. However, if you are interested in
keeping your data secure, recognize that the first two methods were
cryptanalyzed years ago (see H.F. Gaines which was *republished* in
1955!) and should probably not be used in situations requiring
impressive security. Your third option is the OTP, but it doesn't
specify a truly random source -- it specifies instead a "prng" which
would be a weak point of attack in your system. So, use a good one, such
as a BlumBlumShub generator.

In article <[EMAIL PROTECTED]>,
  Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> A classical polyalphabetical substitution table is a square
> matrix with size equal to the cadinality n of the alphabet,
> because an element of the key can be any of the characters
> in the alphabet. It can obviously be advantageous (and easily
> realizable nowadays with computers) to have larger tables,
> i.e. with more columns than hithertofore, so that longer
> key sequences (e.g. those generated somehow from shorter
> keys input by the user) can be employed without much frequent
> repeated use of the same columns of the substitution tables.
>
> I can see three different ways of employing such larger
> substitution tables.
>
> 1. Let the key sequence be divided into groups of k characters
>    and there be m substitution tables. The first group uses
>    the first table, the second group the second, etc. till one
>    wraps round to the first table.
>
> 2. Use some of the last bits of the previous plaintext character
>    to determine the substitution table to be used.
>
> 3. Number the ensemble of columns with numbers 0 to g. Use,
>    instead of key sequences in the traditional sense (whose
>    elements are characters of the alphabet), pseudo-random
>    numbers in the range [0, g] as the key sequences.
>
> I should appreciate knowing other and possibly superior ways
> of employing larger substitution tables.
>
> M. K. Shen
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Greg <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Thu, 08 Jun 2000 19:56:10 GMT

I am pretty certain this is a ruling that effects all of America.  I
know in CA there is a stink about hispanics voting at multiple
precincts.  They get on a bus and travel from one voting booth to
another all day long.  They are not required to show identification
because that would violate their rights.

For example, when you register to vote, you surrender your right to
self incrimination.  Therefore you are not required to register.  I
think this is the basis of the argument itself.

On the other hand, perhaps where you live the rule is the same and like
in CA those at the ballot box do not know or refuse to acknowledge
(unless you press them) the facts of the law.

I know if I tried to do this, there would be a few eye brows raised and
they may not allow you to vote.  In other cases, they force you to sign
with a pencil or refuse you a ballot - they do this so they can adjust
the votes later (and erase the fact that you even came in to vote) -
but that is another form of voter fraud.

Perhaps the ruling only applies to CA.  I thought it was national.  But
as significant as CA is, the problem must be addressed.  CA has a LOT
of voter fraud - much more than you realize.

--
Tyranny is kept at bay by guns and will.  Our government
knows we have the guns, but they don't know if we have
the will.  Nor do we.
The only lawful gun law on the books- the second amendment.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Greg <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Thu, 08 Jun 2000 20:01:00 GMT


> > A person cannot be compelled to identify himself (according to the
> > SCOTUS) but we must have a mechanism in place to ensure that each
> > person casts only one vote and no more.  This is one of the easiest
and
>
> This sounds like demanding a perpetum mobil. The only way to ensure
> absolutely correct voting seems to require at the minimum nonforgeable
> ID cards or their equivalents that uniquely map to the physical
persons,
> I conjecture. BTW, I am surprised to learn that the US voting system
is
> so vulnerable at its foundation.

Read Vote-Scam by Devvy Kidd (www.devvy.com) and you would be
absolutely amazed as to how fragile and corrupt our system is.

There is an element of logic that a person should have to identify
themselves in order to vote.  On the other hand, to assign a penalty to
the task of identification is to forfeit's one's right to self
incrimination.  That, I believe, is the crux of the matter.

When people hear about "Meranda", they think "your rights explained by
a peace officer".  But in fact, the Meranda decision was far more
brutal against government interference in our lives than most realize.
The most significant portion of the Meranda decision stated that the
government cannot compell a person to identify themselves and that
people are not required to carry identification of any sort on their
person, even when walking the streets late at night.  But that is
another story.

--
Tyranny is kept at bay by guns and will.  Our government
knows we have the guns, but they don't know if we have
the will.  Nor do we.
The only lawful gun law on the books- the second amendment.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Thu, 8 Jun 2000 13:20:15 -0700

This is inexcusable. I asked for input and you personally attack the
respondents. Personal attacks on someone else's knowledge, agenda or motives
is not cool. Were I come from, stating that some one lies is the gravest
insult. Its reckless and gratuitous use is a sign of shallowness.

<This is a bunch of BS and you should know better.

<So your point is not valid, and please don't spread such lies.

If you have a personal problem with this guy, take it off line.

Paul






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

From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: software protection schemes
Date: 8 Jun 2000 13:51:42 -0600

>> As I thought we agreed the last time someone asked that question and was
>> pointed at that trade rag, DO NOT look at "Embedded Systems Programming"
>> unless you what you need is at best superficial.  That magazine is suitable
>> only if you've never before thought about the subject or cannot think very
>> well.

In article <[EMAIL PROTECTED]>,
Joseph Reuter  <[EMAIL PROTECTED]> wrote:

>                         ...  But, sometimes I'm surprised and 
>actually learn something, and sometimes I'm entertained, if not 
>informed. In the long run, I find it worthwhile to spend an 
>occasional lunch hour reading it.


In article <[EMAIL PROTECTED]>,
Mike Rosing  <[EMAIL PROTECTED]> wrote:

>I don't disagree.  It's just that the original question didn't even
>understand
>the problem, and that article would give them a place to start.
>
>Just because something is worthless to you doesn't make it worthless in
>general.

I'd have more sympathy for the trade press if I did not know so many people
who not only consider themselves technical experts based entirely on lunch
hour uncritical skimming, but have sold themselves as experts to legions
of users, customers, and managers.  If I didn't spend so much time fighting
the misinformation that results from the trade rags, I could just ignore
them.  Continually encountering people who insist on doing things that
break what I need to do or trying to force me to do things that are
completely wrong, based on their own or their supposed expert's misreading
of trade rag drivel prevents me from just looking away.

Your defenses of trade rags are equally good as defenses of the supermarket
tabloids.  Both are ok for wasting time at lunch, if you don't mind picking
up lots of misinformation.  Both do little harm if you already know the
facts.  Both do real harm to the extent that anyone (including you) pay
any attention to them without checking other sources.

Both of you ignored my reference to the even worse article,
http://www.embedded.com/internet/0004/0004ia2.htm

In other words, even for light lunch time reading, why not read
publications that at least pretend to care about accuracy?  Why
prefer "The National Inquirer" to the "Wall Street Journal"?
How can you ever refer naive people who clearly and admitedly have
not basis to judge to supermarket tabloids?

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

From: [EMAIL PROTECTED]
Subject: Re: Random IV Generation
Date: Thu, 08 Jun 2000 20:16:14 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Charles) wrote:
> I'm currently puzzling over how to generate an IV to get a Blowfish in
> CBC started.  I need 64 random bits, but I'm unsure how to actually
> collate them.  The following options immediately come to mind:

What you could do is hash the current time of day with md5 and xor the
uppermost 64 bits with the lowermost 64 bits. That will sort-of evenly
spread the bits around. While it subtracts from the entropy of just
using the time of day all by itself, it at least makes the bits depend
upon each other fairly well. (whereas using the time of day causes all
IVs used to start with "96" for the next 110 days, 97 for 111 (or so)
days, etc..)

Whether that helps the strength, I dunno.

And, if you do decide to use sha1, I think truncating ought to work too,
I have seen that used in more than a few places.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Greg <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Thu, 08 Jun 2000 20:21:00 GMT


> ...partial solutions on computers look very very dangerous.
>
> Not so much because of malice. but just simple stupidity is
> enough.

I agree that for the bulk of those working to ensure good voter turn
out, there is a desire to make things faster and easier and they don't
have a clue as to how all the technical gizmos can be corrupted by one
who wants to change the votes.  But I am certain there are a few in the
pot who deliberatly want technology to advance voting in America so
they can manipulate the outcomes.  In fact I would lay my reputation on
this being the case (what a slam dunk).


> Counting ballots is tedious to do by hand, and error-prone.

But it is FAR MORE verifiable and therefore prone to far less malicious
error than any other form of counting known to man today.

I wonder just how many people would show up on average at the precinct
later in the night to witness the vote counting- just how much are
people really interested in verifying the accuracy of their vote
counters?  It would be very interesting to see.  But we do not have
this luxary- we are forced to trust them.  This is the kernel of the
scam.

> Doing everything on a computer sounds like a great labor...

This is exactly why they get away with the scam- it "sounds" great.

> Then they break or worse. Nevada has computerized voting machines in
> polling booths; some people here aren't too happy with them -- and
that's
> the model which is comparatively *easy* to deal with.

And I wonder how many people refuse to vote because of this.  Did you
know that NV state legislature was composed of many patriotic men and
women who passed a bill (though I do not know if it actually became
law) to mint their own coins?  They were going to mint their own Nevada
silver dollars with real silver and fling it in the face of the US
government.  Their position was, "Unless and until you abide by the US
constitution to coin money exclusively, neither shall we abide by the
same."  In other words, they were saying that the US must not allow the
FED to coin money or they would coin money also.  And since their coins
used real sivler there would be a true dual economy competing for
Americans to operate under.  And since the FED note is no longer based
on precious anything but are merely debt, NV coins looked real good.

This came to mind as I read your post.  No doubt such space age
technology was put into NV to prevent such patriotic and law abiding
citizens from entering power there again.  The FED must not be
embarrassed at any cost.  And I mean at all costs.

Did you know JFK was assassinated three weeks after signing an EO that
would force the federal government to coin money apart from the FED?
Coincidence?  I don't believe so.

JFK was the first and only president that stood up to the NWO (calling
Kissinger a mad man that was never permitted to enter the white house
grounds) and tried to take back our government from the powerful forces
that ultimately took him from us.  And they feared his brother Robert,
but they seem to like Teddy (perhaps he was corrupted too much to stand
in the light of day?).

--
Tyranny is kept at bay by guns and will.  Our government
knows we have the guns, but they don't know if we have
the will.  Nor do we.
The only lawful gun law on the books- the second amendment.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: AllanW <[EMAIL PROTECTED]>
Subject: PGP Self-Decrypt
Date: Thu, 08 Jun 2000 20:26:15 GMT

I've heard that new versions of PGP have a "self-decrypt" mode
that lets you send encrypted data to someone without PGP. But
how does this work?

If the recipient doesn't need PGP, then this can't support
public-key encryption, right? Does it ask for a password?

If it uses a password to decrypt, isn't it vulnerable to
brute-force attacks?

If it doesn't even need a password, doesn't that mean
that it can be "decrypted" by anybody that receives it?

--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Extending the size of polyalphabetic substitution tables
Date: Thu, 08 Jun 2000 23:15:36 +0200



[EMAIL PROTECTED] wrote:

> MK, I suppose it depends upon your needs. If you are mainly interested
> in methods of historical ciphers, sure, these methods will be nice
> extensions of previous ciphers. However, if you are interested in
> keeping your data secure, recognize that the first two methods were
> cryptanalyzed years ago (see H.F. Gaines which was *republished* in
> 1955!) and should probably not be used in situations requiring
> impressive security. Your third option is the OTP, but it doesn't
> specify a truly random source -- it specifies instead a "prng" which
> would be a weak point of attack in your system. So, use a good one, such
> as a BlumBlumShub generator.

1. In modern block ciphers, the so-called S-boxes are columns of
    substitution tables. I was addressing the case of using more columns,
    keeping the classical context so that it is easier for me to explain.
    The basic ideas could be transfered to the modern designs.

2. As you pointed out, I didn't specify what PRNG to use. In the context
    of my post, it is also not necessary and in my opinion not appropriate
    to specify that. Why do you specifically call attention here of a
special
    PRNG? Are you doing marketing for it, perhaps?

M. K. Shen




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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Thu, 08 Jun 2000 23:16:02 +0200



[EMAIL PROTECTED] wrote:

> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > Thank you for the valuable informations. This confirms the
> > appropriateness of the restriction in my assumptions (see follow-ups
> > later than the first post in the thread) that n-gram frequency
> > distributions are not exploitable by the opponent (to be rendered
> > flat through appropriate measures).
>
> MK, if you are attempting to reuse a pad to save on key-transmission
> costs, would your purposes be better served by using 64 bits of what
> would be your 'pad' as input to a BlumBlumShub generator to be iterated
> a few times and the result[s] to be used as a key for an AES candidate,
> or des-ede, or something similar? After each message, you could slide to
> using a different set of bits from the 'pad' to generate a new key.
> Wouldn't this solve the trouble of reusing pads, while doling out the
> available entropy a bit better? [pun not intended, but I like it enough
> I am leaving it in. :]
>
> By the use of the BBS, I *think* this will stir things around s.t. reuse
> of entropy bits will not cause a problem. If it will, then you could
> simply use a different 64 bits from the 'pad' as your future keys..

If you have read some of my posts in this thread, you would have read
that my intention is to study whether and why accidental misuse of
OTP could be very critical and not to recommend/propagate the
use of OTP. So, since there exists no 'purpose' of mine to use the
OTP at all, your suggestion to 'better serve' that 'purpose' doesn't apply
in my view.

M. K. Shen







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


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