Cryptography-Digest Digest #981, Volume #9        Tue, 3 Aug 99 19:13:02 EDT

Contents:
  Re: Is the output of 3DES really pseudorandom??? (fungus)
  Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big   is  a Byte?) 
(Martin Ambuhl)
  Re: CFB mode with same initialization vector (Daniel Vogelheim)
  Re: [Q] Why is pub key cert. secure & free from spoofing? (Greg)
  OT: Bad C programming (was: What the hell is XOR?) (fungus)
  The Acronym MDC (John Savard)
  Re: Blowfish x86 assembler (Gord)
  Re: Is breaking RSA NP-Complete ? ([EMAIL PROTECTED])
  Re: Cryptanalysis of R250 (John Savard)
  Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big   is  a Byte?) 
(Greg Comeau)
  Re: OTP export controlled? (wtshaw)
  Re: OTP export controlled? (wtshaw)
  Re: Prime number. (John McDonald, Jr.)
  Re: Prime number. (Anton Stiglic)
  Re: The Acronym MDC ("karl malbrain")
  Re: Blowfish x86 assembler ([EMAIL PROTECTED])

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

From: fungus <[EMAIL PROTECTED]>
Subject: Re: Is the output of 3DES really pseudorandom???
Date: Tue, 03 Aug 1999 22:38:26 +0200



Michelle Davis wrote:
> 
> Can you call the output of 3DES cryptographically pseudorandom? Common
> sense tells me since the cipher is effective, its output has to appear
> random.

Correct.

If you could predict the output from the input block then we'd have
a security problem, ne'st pas?

> But is it comparable to something generated by a decent
> pseudorandom number generator?
>
 
The difference is that 3DES is likely to be much slower than
a good pseudo-random number generator.


> What kind of analytical technique could you use to tell
> the pseudorandom string from the ciphertext?

Now we're back to the random number thread. <sigh>

Answer: No statistical test can ever tell you if a number is
random - you can't prove a negative.



-- 
<\___/>
/ O O \
\_____/  FTB.

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

From: Martin Ambuhl <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big   is  a 
Byte?)
Date: Tue, 03 Aug 1999 15:51:31 -0400



Greg Comeau wrote:
> 
> In article <[EMAIL PROTECTED]> Martin Ambuhl <[EMAIL PROTECTED]> 
>writes:
> >
> >
> >"Lame K. Irony" wrote:
> >
> >> By the way, I'd like to point out the obvious fact that if the word "byte"
> >> did NOT mean an eight bit binary number, then it would necessary for us to
> >> create a word that DOES have that meaning, since there is certainly a need
> >> for such a word. In my opinion, the fact that no other such word exists is
> >> ample evidence that "byte" fits the bill.
> >
> >Next time you get involved in a thread, stay awake.  There have been
> >numerous uses of "octet" in this thread.  Somehow people have been using
> >a word that that does not exist.
> >
> >If you think "byte" works with the meaning "8-bits", explain what the
> >PDP-10 insruction LoadBytePointer is supposed to do when someone tries
> >to use one of the other 35 allowed sizes (any size 1-36) works.
> 
> I think we can help each other here, and still avoid "insults"
> like "stay away".  Please reconsider such.  Thanks.

Greg, "stay awake" and "stay away" are completely different.  There are
no insults in my mesage.  After numerous postings by several different
people using the term "octet", the poster stated flatly that there was
no term for an 8-bit binary number.  This indicates a very high level of
inattention, so my admonition to "stay awake".  

Please don't look for insults where there are none, and certainly don't
rewrite "stay awake" to "stay away" in an effort to create one.


-- 
Martin Ambuhl   [EMAIL PROTECTED]

__________________________________________________________
Fight spam now!
Get your free anti-spam service: http://www.brightmail.com


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

From: [EMAIL PROTECTED] (Daniel Vogelheim)
Subject: Re: CFB mode with same initialization vector
Date: Tue, 03 Aug 1999 19:51:24 GMT

Hello,

Peter wrote:
>> > The danger is that you might encrypt plaintexts whose
>> > beginnings are identical, thereby producing ciphertexts
>> > whose beginnings are identical. 

Paul wrote:
>> Not quite.  If the first two plaintext (resp. ciphertext) blocks
>> of two different messages are P1 and P1' (resp. C1 and C1') then
>> with the same IV used you'll get C1 XOR C1' = P1 XOR P1' thus
>> leaking lots of info about the first plaintext blocks.

Peter wrote:
>Eeek! Dead right! All this time I was reading "CBC" for "CFB".

I don't see a contradiction here. If all inputs (password, IV and
plaintext) are identical, so will be the output; after all, the
algorithms are deterministic. (So this applies to CBC as well as CFB.)
Being deterministic as such is not considered a weakness AFAIK :-) ,
but I see the problem. It's nice that streaming modes provide a way
around this by chosing different IVs.

So we can say:
      "CFB (same key, same IV) yields identical output for identical
      input, and the plaintext XOR of the first non-identical block
      can be recovered."
With no common prefix this yields Paul's answer, and ignoring the
second part yields Peter's.

[ Of course, one could also argue that chaining modes should be such
that subsequent data affects previous data, making the above
impossible. This is what David was probably getting at. However, in my
case it wouldn't work, as I'm looking at a dialogue-style
communications system, where answers need to be sent before the
communication ends. In other words, partial results need to be
encrypted and decrypted, before the subsequent data is even known.
Btw., in this setting, error recovery is also highly desirable, which
David's test-for-weakness in his recent posting in this thread would
not allow. ]


And now for something different: Also, one could relate the XOR one
one ciphertext-block to the XOR one the next. The first is the
input-differential of the block cipher, and the second the
output-differential XOR the two data values. This could probably be
used to mount a differential cryptanalysis using ciphertexts only
(rather than known plaintexts). (I suppose this would only work if
enough statistical properties about the plaintext XORs were known.)


Ahh, this is all interesting, but it still doesn't explain:

      "If the IV in CFB is not unique, a cryptanalyst can 
       recover the corresponding plaintext." (AC2, p.201)

I understand this as: 
      "There is an attack that recovers the full plaintext from 
       known ciphertext in a reasonable amount of time." 
(If more needed to be known, or the time was prohibitive, or it only
worked with some low probability, Bruce would probably have restricted
the claim accordingly.) So... How does it work? Where can I read more
about it?


Thanks,
Daniel


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

From: Greg <[EMAIL PROTECTED]>
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: Tue, 03 Aug 1999 19:50:32 GMT


> Once you have these certificates, then you can
> trust that the public keys
> on these certificates belong to the CAs
> as claimed, because you got them
> through a trusted channel.  From that
> point on, you can choose to accept
> only those additional keys that have
> been signed by one of the CAs.  You
> can verify that the CA actually signed
> the key, because you have their
> public key, and you trust it.

You hit the nail on the head.  You are correct when you say that you
can be certain that a certificate signed by XYZ is from XYZ.  That is
all the protocol can verify - who a certificate COMES FROM.  The
protocol cannot verify the accuracy of the certificate.

Let me make it really simple: The accuracy of a certificate is
inversely related to your ability to bribe an individual within the
CA.  Now all of the sudden, security flies out the window, but CA are
pushed along anyway BECAUSE E-COMMERCE MEANS $$$!

--
The US is not a democracy - US Constitution Article IV Section 4.
Democracy is the male majority legalizing rape.
UN Security Council is a Democracy.  NO APPEALS!  Welcome to the NWO.
Criminals=Crime.  Armies=Tyranny.  The 2nd amendment is about tyranny.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: fungus <[EMAIL PROTECTED]>
Subject: OT: Bad C programming (was: What the hell is XOR?)
Date: Tue, 03 Aug 1999 23:16:56 +0200

[EMAIL PROTECTED] (John M. Gamble) responded:
> In article <[EMAIL PROTECTED]>,
> fungus  <[EMAIL PROTECTED]> wrote:
> >void swap(int *a, int *b)
> >{
> >   *a ^= *b;
> >   *b ^= *a;
> >   *a ^= *b;
> >}
> >
> >Can fail...
> >
>
> But good heavens, why would you do it like that?
>
> /*
> ** Swap via the three-xor method, contained in a single line.
> */
> #define swap(a, b)      (a ^= (b ^= (a ^= b)))
>

It can still fail, eg.


typedef struct foo_s {
int n;
} foo;

#define swap(a, b)      (a ^= (b ^= (a ^= b)))

void bar(foo *a, foo *b)
{
  /* Do something */

  swap(a->n, b->n);

  /* Do something else */
}


This will fail if (when) a = b.


If pointers can possibly be involved, anywhere in the program, then
*don't* use this silly trick.


-- 
<\___/>
/ O O \
\_____/  FTB.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: The Acronym MDC
Date: Tue, 03 Aug 1999 21:27:07 GMT

I had thought that MDC stood for Message Digest Code, but according to
the Handbook of Applied Cryptography, it stands for Modification
Detection Code!

Evidently, the field is suffering from terminological overload...or
it's just my memory that is fallible.

John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: Gord <[EMAIL PROTECTED]>
Subject: Re: Blowfish x86 assembler
Date: Tue, 03 Aug 1999 16:10:52 -0500

[EMAIL PROTECTED] wrote:
[snip]
> If you could send the file(s) to '[EMAIL PROTECTED]' I wouldn't
> mind checking it out.  no guarantees though. I promise I won't 'run
> off' with your code though.

Is that the same empty promise you made when you ran off with SCOTT19U
?!  :P

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

From: [EMAIL PROTECTED]
Subject: Re: Is breaking RSA NP-Complete ?
Date: Tue, 03 Aug 1999 20:56:55 GMT

Anton Stiglic wrote:

> def.   (NP-Hard)
>    A problem (any problem, no just a decisional problem
> (important distiction)) is NP-hard if the existence of a
> polynomial -time algorithm for its solution implies
> that P = NP.

As noted, references disagree on this one.  Cormen,
Leiserson & Rivest, /Introduction to Algorithms/
defines NP-Hard as a set of languages, saying that
a language is NP-Hard if any language in NP is
polynomially reducible to it.

Note that the two definitions disagree about more than
whether NP-Hard is a set of languages.  If P!=NP, then
there are subsets of NP that are neither in P nor
NP-Complete.  These languages would be NP-Hard under
the definition in the Handbook, but not under the
definition in /Introduction to Algorithms/.

--Bryan


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cryptanalysis of R250
Date: Tue, 03 Aug 1999 21:45:03 GMT

[EMAIL PROTECTED] () wrote, in part:

>has led me to the conclusion that R250 is also known as the Tausworth
>generator, and the algorithm is as follows:

>I(n) = I(n-147) XOR I(n-250)

Actually, R250 and the Tausworth generator are not identical, as I now
see from revisiting the sites involved with a graphical, instead of a
text, browser, in which I can see equations:

I(n) = I(n-103) XOR I(n-250)

is the formula for R250, and thus it is based on the same polynomial,
and has essentially the same period and weaknesses.

John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big   is  a 
Byte?)
Date: 3 Aug 1999 17:06:02 -0400
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]> Martin Ambuhl <[EMAIL PROTECTED]> 
writes:
>Greg Comeau wrote:
>> In article <[EMAIL PROTECTED]> Martin Ambuhl <[EMAIL PROTECTED]> 
>writes:
>> >"Lame K. Irony" wrote:
>> >> By the way, I'd like to point out the obvious fact that if the word "byte"
>> >> did NOT mean an eight bit binary number, then it would necessary for us to
>> >> create a word that DOES have that meaning, since there is certainly a need
>> >> for such a word. In my opinion, the fact that no other such word exists is
>> >> ample evidence that "byte" fits the bill.
>> >
>> >Next time you get involved in a thread, stay awake.  There have been
>> >numerous uses of "octet" in this thread.  Somehow people have been using
>> >a word that that does not exist.
>> >
>> >If you think "byte" works with the meaning "8-bits", explain what the
>> >PDP-10 insruction LoadBytePointer is supposed to do when someone tries
>> >to use one of the other 35 allowed sizes (any size 1-36) works.
>> 
>> I think we can help each other here, and still avoid "insults"
>> like "stay away".  Please reconsider such.  Thanks.
>
>Greg, "stay awake" and "stay away" are completely different.  There are
>no insults in my mesage.  After numerous postings by several different
>people using the term "octet", the poster stated flatly that there was
>no term for an 8-bit binary number.  This indicates a very high level of
>inattention, so my admonition to "stay awake".  
>
>Please don't look for insults where there are none, and certainly don't
>rewrite "stay awake" to "stay away" in an effort to create one.

If you told me to "stay away" (I made a typo, nothing more, nothing less)
I would be insulted.  If you told me to "stay awake" I would still be insulted.
I'm not looking for anything but some to the point issues w/o the
extra narratives that often come along with them (and even w/o them).

- Greg
-- 
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com *** 

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

From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Tue, 03 Aug 1999 16:05:20 -0600

In article <[EMAIL PROTECTED]>, Paul Koning <[EMAIL PROTECTED]> wrote:

> "W.G. Unruh" wrote:
> > ...
> > >It is ludicrous to think that export regulations can really keep
> > >foreigners from implementing decent encryption.
> > 
> > Not their purpose.
> 
> It IS the stated purpose.  It has to be for it not to be laughed
> out of the room.
> 
> > Their purpose is to pervent US residents from providing
> > foreigners with decent encryption. 
> 
> I don't think so.  If you mean the unstated purpose (or not so
> clearly stated purpose), that is to keep strong crypto out of
> the hands of US residents.  Look at Freeh's testimony, it's
> clear enough if you read it carefully.

I was agreeing with the last poster.  If the goals of the export regs are
to keep crypto out of the hands of foreigners, there should not be a
loophole to let any of them get it here.
-- 
MY lock, MY key.

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

From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Tue, 03 Aug 1999 16:03:32 -0600

In article <[EMAIL PROTECTED]>, Paul Koning <[EMAIL PROTECTED]> wrote:

> "W.G. Unruh" wrote:
> > ...
> > >It is ludicrous to think that export regulations can really keep
> > >foreigners from implementing decent encryption.
> > 
> > Not their purpose.
> 
> It IS the stated purpose.  It has to be for it not to be laughed
> out of the room.
> 
> > Their purpose is to pervent US residents from providing
> > foreigners with decent encryption. 
> 
> I don't think so.  If you mean the unstated purpose (or not so
> clearly stated purpose), that is to keep strong crypto out of
> the hands of US residents.  Look at Freeh's testimony, it's
> clear enough if you read it carefully.

Sure it is, tie everything up in red tape and spread fear, which is the
not the way to run a government, at least not here.
-- 
MY lock, MY key.

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

From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Prime number.
Date: Tue, 03 Aug 1999 20:58:33 GMT

On Tue, 03 Aug 1999 06:52:42 -0400, Anton Stiglic <[EMAIL PROTECTED]>
wrote:

>That response was completly out of track for crypto purposes..
>
>First of all, if you are using primes that can fit in a double, 
>it is not a big enough prime,you need special types, see SSLeay 
>for example.  Even if you choosed a prime p, say, 50 bits, that 
>could be secure to some extent, you will surely have to compute some
>values on that, say exponentiation p^2, and then your value explodes
        You are correct.  If he wants to do a value that is greater
than 32 bits he will need to use a special type. This is true only if
he needs to square it, in which case he needs a total of 64 bits.
Otherwise, to multiply, he need only add up the bits for each number.
It depends on the necessary calculations.

Incidentally, I apologize. I didn't mean double.  I meant __int64 in
C++, or a long in java.  Either of these will give you 64 bits to work
with, which should be enough for simulation.

>Secondly, to test if a number is prime, you don't use the technic mentioned,
>don't _ever_ use that technic if you are using big primes (wich you will 
>_always_ be using in crypto).
        And why not use this method?  It is actually very quick, and
very efficient, and THE ONLY way to be 100% sure that the number you
are testing is indeed prime.  Other methods can give you good
certainty, (99% even), but for very large numbers, as you say there's
a lot of numbers to check, and a lot of possible pitfalls.

        As to the efficiency of this algorithm... We used this
algorithm to find and test the first 1,000,000 primes.  This process,
using this algorithm took slightly less than 5 minutes. I beg you to
show me another algorithm that does the same amount of work with 100%
accuracy in the same amount of time. Please.  I really would like to
have it... 
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
 John K. McDonald, Jr.      Alcatel, USA

 [EMAIL PROTECTED]
 please remove -delete- for responses.
 --
 "I speak for me and not this company"

 TO SPAMMERS:
 Please  view   the  definitions   for 
 "telephone     facsimile    machine," 
 "unsolicted  advertisement,"  and the
 prohibition  and penalty  for sending
 unsolicited faxes before sending  Un-
 solicited  Commercial   E-mail to the 
 above   address.   Violators  WILL BE 
 PROSECUTED.   These   can   be  found
 in:
 
 The Telephone Consumer Protection Act
 of  1991,    Title   47,   Chapter 5,
 Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]

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

From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Prime number.
Date: Tue, 03 Aug 1999 06:53:57 -0400



If it's just a simulation, it's o.k. to use double, but still, use a more
intelligent
test for primality.....


Anton


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

Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: The Acronym MDC
Date: Tue, 3 Aug 1999 14:41:39 -0700


John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I had thought that MDC stood for Message Digest Code, but according to
> the Handbook of Applied Cryptography, it stands for Modification
> Detection Code!
>

The two terms are equivalent from a practical standpoint, so there is no
confusion possible.  Karl M



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

From: [EMAIL PROTECTED]
Subject: Re: Blowfish x86 assembler
Date: Tue, 03 Aug 1999 23:01:58 GMT

In article <[EMAIL PROTECTED]>,
  Gord <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> [snip]
> > If you could send the file(s) to '[EMAIL PROTECTED]' I wouldn't
> > mind checking it out.  no guarantees though. I promise I won't 'run
> > off' with your code though.
>
> Is that the same empty promise you made when you ran off with SCOTT19U
> ?!  :P

What are you talking about?  I downloaded his code, posted my initial
thoughts to the group.  When I had severe questions like

1) rounds/block size ratio (for given security against iteratize
attacks)
2) Security vs. word size
3) keyschedule complications (only 1/3 of a percent of all possible
permutations are single cycle) ...

He never answered...  That's why I gave up.  I have serious questions
about the 'security' in Scottu methods...

About this code, I want to view it and see if I can notice any speed
bumps. Not cryptanalyze it...

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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


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