Cryptography-Digest Digest #92, Volume #11       Thu, 10 Feb 00 21:13:02 EST

Contents:
  Re: question about PKI... ("Joseph Ashwood")
  Re: Does hashing an encrypted message increase hash security? (Erann Gat)
  Bounding (p-1)(q-1) given only knowledge of pq ("Joseph Ashwood")
  Twofish vs. Blowfish (Albert Yang)
  Re: I'm returning the Dr Dobbs CDROM (JD)
  Re: Opinions please: Serpent (John Myre)
  Re: Using Gray Codes to help crack DES ([EMAIL PROTECTED])
  Period of cycles in OFB mode (Tim Tyler)
  Re: I'm returning the Dr Dobbs CDROM (Vernon Schryver)
  Somebody is jamming my communications -- this has been happening at  ("Markku J. 
Saarelainen")
  Re: "Farscape" CD-Rom (Roman Kiley)
  Re: I'm returning the Dr Dobbs CDROM (Jerry Coffin)
  Re: Somebody is jamming my communications -- this has been happening at   least in 
three separate communication (Jerry Coffin)
  Re: Somebody is jamming my communications -- this has been happening at  
("-=HaVoC=--")
  Re: New standart for encryption software. (Peter Gutmann)
  Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
  Re: new standart for encryption software... (Peter Gutmann)

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: question about PKI...
Date: Thu, 10 Feb 2000 13:42:10 -0000

> There's no flaw in the logic of using SRP or any
> zero-knowledge protocol to strengthen the weak links
> in a PKI system.  SRP, SPEKE, EKE and related
zero-knowledge
> methods are designed specifically tolerate small, easily
remembered
> secrets, without the vulnerability to network attack of
older
> protocols.

What I meant was that in a single server context where I
proposed it to him made for a rather muddy perception of
effectiveness, in spite of this the perception was probably
correct (the perception being that SRP provides an easy way
to a secure environment for the transfer of the key).

> Kerberos V4 and V5 initial authentication are very much
unlike SRP,
> and Kerberos would be greatly improved by using any of
these
> zero-knowledge methods.

I absolutely agree. I think it might even be useful for
someone on this group (perhaps even me) to begin such a
process. Anybody wanna add themselves to the byline? Some
work required.

> Two original design requirements behind Kerberos were to
> be free, and to avoid using any computationally expensive
> operations.  You can judge for yourself whether this
philosophy
> is still appropriate for commercial products and modern
CPUs.

For a normal network where the logins are either few, or
there are enough to warrant multiple login servers, the
requirement is no longer there. The new requirement is it
must be windows. I guess before I go about getting this on
anything big, I'll have to write a login for windows.
                    Joe



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

From: [EMAIL PROTECTED] (Erann Gat)
Subject: Re: Does hashing an encrypted message increase hash security?
Date: Thu, 10 Feb 2000 13:44:09 -0800


Thanks to all who responded.  By "increased security" I did indeed mean
second preimage resistance.  I asked because I read somewhere that MD5
was insecure and that I should use SHA instead.  But I have an implementation
of MD5 in hand and I don't have an implementation of SHA and I was
wondering if my quick-and-dirty hack would work to give me a secure
hash that was more secure than MD5 without going through the trouble
of implementing SHA.

E.

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Bounding (p-1)(q-1) given only knowledge of pq
Date: Thu, 10 Feb 2000 14:08:43 -0000

For let me say that I'm not sure this information is new,
but to the best of my knowledge it was never told to me.

For those of you that couldn't tell solely from the subject
line, this has to do with RSA. I cannot push this further to
determine an exclusive d, but given a list of possible d's
this observation makes it possible to eliminate some of the
possibilties.
Assumptions: p and q are primes, working in binary, p and q
are interchangable
Simple observation: (p-1)(q-1) MUST be smaller than pq
It is also possible to place bounds on p and q and through
them place bounds on p-1 and q-1
Typical bounds are that p and q are of equal length

p-1 must be the same size as p
q-1 must be the same size as q

(p-1)(q-1) will be the same size as pq
The ratio between them ((p-1)(q-1)/pq) is 1-(p+q-1)/pq
(equation 1)

Notice that as p and q grow larger the ratio converges to 1

Given this, and a candidate d (as from the equation de = 1
mod (p-1)(q-1) (equation 2) it is possible to determine if d
if in fact a proper candidate.

Also notice that equation 2 can be restated as
de = 1 + k(p-1)(q-1)
the last 2 bits of de must be 01 since (p-1)(q-1) must be
divisible by 4
It can also be noted that because we have both an upper and
lower bound on (p-1)(q-1) (which will vary depending on the
level of knowledge of the generation method) we can assert
the following

de > k(minimum p - 1)(max q-1)
de < k(pq - 2)
for some k

if such a k does not exist d can not solve the equations
needed to produce the RSA encryption algorithm.
                    Joseph Ashwood



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

From: Albert Yang <[EMAIL PROTECTED]>
Subject: Twofish vs. Blowfish
Date: Thu, 10 Feb 2000 22:23:05 GMT

Hmm, my company is probably going to use blowfish for its needs, but I
was wondering, should I trust blowfish more because it's got a lot of
crypto-analysis behind it (and Bruce says that is the real definition of
"strength" of a crypto algorithm) or to go with say, Twofish, which has
better design, faster, but less research?

Thoughts?  Bruce?

Albert

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

From: JD <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Thu, 10 Feb 2000 22:38:16 GMT


>     I am returning the CDROM because it is not suitable for printing.
> For example, to print chapter 1 of the Stinson book (44 pages) Adobe
> acroread (x86/Solaris 2.6) creates a 500MB postscript file.  I cannot
> print this file directly, probably because it is too big.  Although I
> might be able to find a way to print the file, at 500MB it would take
> too much time.

Something is wrong.  PDF is just glorified PostScript, so the PS output
should be not much larger than the original PDF file.  In this case,
theory1.pdf is 2.2MB.  When I print the 44 pages to a PS file using
acroread 4.0 on Solaris (SPARC), the result is 3.16MB.  When I do
the same using the Adobe PS driver 5.1 on WinNT, it is 2.9MB.  So
whatever you're doing is off by a couple orders of magnitude.

--JD


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

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Opinions please: Serpent
Date: Thu, 10 Feb 2000 16:18:36 -0700

JCA wrote:
> 
>     Serpent is one of the final five contenders (together with MARS, RC6,
> Rijndael
> and Twofish) in the race to become AES.

It's probably worth noting that Serpent is generally regarded as
having the most conservative design - it isn't it's speed that got
it into the final five.

JM

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

From: [EMAIL PROTECTED]
Subject: Re: Using Gray Codes to help crack DES
Date: 10 Feb 2000 23:23:49 GMT

In article <87v9jl$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Nick 
> Does Anyone know where I can get an explanation of what greycodes are 
> and their uses in cryptography?
 
A Graycode is system of counting where there is only ever one bit 
difference between adjacent values.  A 2-bit sequence would be:

  00
  01
  11
  01

Their main (non-crypto) use has been in devices such as angle encoders 
where the 1-bit difference meant that the maximum error was only +/- 1 LS 
bit.
  

Keith
 http://www.cix.co.uk/~klockstone
 ------------------------
 'Unwise a grave for Arthur'
 -- The Black Book of Carmarthen

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Period of cycles in OFB mode
Reply-To: [EMAIL PROTECTED]
Date: Thu, 10 Feb 2000 23:23:41 GMT

It appears to me that when using most block cyphers in OFB mode, there
will exist both weak keys (keys where there exists no period anywhere
near 2^n in length), and - for the vast mayority of keys - there
will be weak IVs (IVs that happen to hit on a shorter-than normal
cycle).

I am interested to learn about what efforts (if any) have been made
to avoid these problems in block cyphers in OFB mode.

It seems to me that the problems are specific to OFB mode.  I don't know
how much attention has been paid to them as a consequence.

Reducing the frequency of small periods seems potentially possible - and
may already be happening to some extent.

I doubt there's a practical way of choosing IVs that are on the longest
period, in a design with more than one cycle.

In researching such questions, I uncovered what /appears/ to be an error
in Schneier's "Applied Cryptography".

On P.205, in a section called "Security problems with OFB", he writes:

``When the feedback size equals the block size, the block cypher acts as
  a permutation of m-bit values (where m is the block length) and the
  average cycle length is 2^m - 1.''

I believe the expected cycle length will be 2^(m - 1), and *not* 2^m - 1.

The proof of this is not quite trivial.  I'll provide it only if it is needed.

I've checked the "errata" at:

http://www.counterpane.com/ac2errv30.html

...and this item is not presently listed.

I'm aware that it's /possible/ to get an OFB cycle length of 2^m.

Do folks know if any serious block cyphers demonstrably do this?
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

Put not your trust in money.  Put your money in trust.

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

From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: 10 Feb 2000 17:29:42 -0700

In article <87v3sv$ger$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:

>> If the contents are only scanned images, then how can you "search and
>> cut-and-paste the text"?

>That's a damn good question that I'd love an answer to myself!  I've
>got several CDs with scanned page images, including the DDJ CDROM, and
>I can cut and paste right out of the scanned image as text.  So either
>Adobe Acrobat is doing OCR on the fly, or there's other meta
>information that's stored in the PDF file (probably from a previous
>OCR pass).  Anyway, I'm not sure why I'd want to cut-and-paste like
>that, but it's pretty cool that you can do it.  The question of "how?"
>remains a curiosity though...

I like to speculate, but I also like to shave my guesses with Occam's
Razor, obvious facts, and back-of-the-envelope sanity checks.

Is there any evidence for the theory that the CDROMs contain only scanned
images besides the size and poor quality of the printed images and the
difficulty of printing individual pages?  Has anyone used something like
`strings` or even `emacs` to look for ASCII text?  Has anyone asked DDJ?

Even if there were meta information from a previous OCR pass, how
would Acrobat relate a position on the screen to individual characters
of meta information during cut-and-paste?  The only way I can see
would spend a lot more bits on the CDROM and CPU cycles during
display and cut-and-paste than other obvious storage formats.

Just how bloated are the CDROMs?  Do I understand correctly that Schneier's
"Applied Cryptography" is present?  The second edition contains 758 pages.
I think 640x480 would be far to low for bit images of that or most books;
displaying 45 lines of 12 pitch text such as in "Applied Cryptography
would be at best very ugly at 640x480 and not a lot better at 1024x768.
At 8 bits/pixel, "Applied Cryptography" in 640x480 images would need at
least 23 MBytes.  At 1024x768 it would fill an entire CDROM.  Don't the
CDROM's contain a lot more than one book?  How many books on the CDROMs?
At what resolution do the books appear on the screen?  Yes, you don't need
8 bits/pixel for only text, but do any of the books have pictures?

A much simpler theory than on-the-fly OCR is that CDROMs are not
bit images, but that the processes that were tried to print chapters
generated bloated bit images, perhaps because the PostScript
machinery used didn't have fancy enough fonts.

A another simpler theory is that the CDROMs do not contain only bit maps
but also the real text and not merely as meta-data.  To deal with
illustrations, they might have images of each page as well as text, and
display or print the text on top of a scanned image with the text masked.
That is a lot simpler than trying to relate a mouse position in a display
version of a bit image to a character for cutting-and-pasting.

For that matter, a very simple theory for the whole story is that
PDF can be used to make it hard to print individual pages in order
to encourage people to buy the paper books.


Vernon Schryver    [EMAIL PROTECTED]

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

From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.israel,alt.2600
Subject: Somebody is jamming my communications -- this has been happening at 
Date: Fri, 11 Feb 2000 01:03:07 GMT


This is real ... and on live .. actually happening ...

Somebody is jamming my communications -- this has been happening at
least in three separate locations  ..

In addition, at one night, when I was in one location and had just
finished uploading the board of the Game of General (M) and clicked to
access the board, the whole LAN came down ...

I suppose the CIA / NSA has initiated the information operation ....

right .. ?

If so .. suck my dick ...




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

From: [EMAIL PROTECTED] (Roman Kiley)
Crossposted-To: alt.tv.farscape
Subject: Re: "Farscape" CD-Rom
Date: Fri, 11 Feb 2000 01:09:15 GMT

[EMAIL PROTECTED] wrote:

>Be sure to check out the latest (April) issue
>of scifi magazine! It includes a Farscape CD-Rom
>with exclusive images, screensavers, and more.
>There's bonus footage too, but you'll have to wait
>for the season premiere on March 17th to unlock it.

Do you have any idea how the "unlocking" works? I have a strong suspicion
that we'll see its contents on some web pages and binary news groups long
before March 17th gets here, unless they know a lot more about cryptography
than most people.
-- 
"Roman Kiley" is actually [EMAIL PROTECTED] (2658 439710).
 01234 56789 <- Use this key to decode my email address and name.
              Play Five by Five Poker at http://www.5X5poker.com.

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Thu, 10 Feb 2000 18:26:35 -0700

In article <87vl5m$315$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...

[ ... ] 

> Is there any evidence for the theory that the CDROMs contain only scanned
> images besides the size and poor quality of the printed images and the
> difficulty of printing individual pages?  Has anyone used something like
> `strings` or even `emacs` to look for ASCII text?  Has anyone asked DDJ?

You wouldn't find it in any case, at least not without doing some 
decoding.  The reason PS files are around double the size of PDF files 
as a rule is that PDF files are normally compressed using LZW.
 
-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.israel,alt.2600
Subject: Re: Somebody is jamming my communications -- this has been happening at   
least in three separate communication
Date: Thu, 10 Feb 2000 18:27:36 -0700

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...
> 
> This is real ... and on live .. actually happening ...
> 
> Somebody is jamming my communications -- this has been happening at
> least in three separate locations  ..

Given the (IMO excessive) number of stupid posts you make, it's too 
bad somebody ISN'T blocking them.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: "-=HaVoC=--" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.israel,alt.2600
Subject: Re: Somebody is jamming my communications -- this has been happening at 
Date: Thu, 10 Feb 2000 17:44:12 -0800

"Markku J. Saarelainen" wrote:

> This is real ... and on live .. actually happening ...
>
> Somebody is jamming my communications -- this has been happening at
> least in three separate locations  ..
>
> In addition, at one night, when I was in one location and had just
> finished uploading the board of the Game of General (M) and clicked to
> access the board, the whole LAN came down ...
>
> I suppose the CIA / NSA has initiated the information operation ....
>
> right .. ?
>
> If so .. suck my dick ...

<spun>
Yeah, sounds like the are on to you pretty bad. I would suggest investing
in a decent scanner. You'll be able to pick up their radio transmissions
in your local vicinity. Helps you get to know their routine/schedule.
Also, if your house looks faces a street, you may wanna put foil over the
windows and open a small hole for surveillance. Keep an eye out, write
down license plates for later reference etc. You are pretty much solo, and
they are all out to get you. So you are going to have to cut back on the
sleep to possibly catch a slip up on their part. They get sloppy from
2:00am on. Oh, and don't leave the bodies in the trunk too long. Get rid
of them as quickly as possible. Good luck...    8-)
</spun>
--
-=HaVoC=-
"Most of the time it was probably real bad being stuck in a dungeon.
But some days, when there was a bad storm outside, you'd look out
the window and think, "Boy, I'm glad I'm not out in that." -anon



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

From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: New standart for encryption software.
Date: 11 Feb 2000 01:27:21 GMT



Albert P. Belle Isle <[EMAIL PROTECTED]> writes:

>Document Security Manager has (for years) made its built-in FIPS 81,
>SP500-20, FIPS 180-1 and FIPS 140-1 self-tests available to the user
>interface. 

[...]

>The ANSI X9.17c keystream generator can produce its next megabyte of
>pseudorandom bytes to disk, on command. The fact that it is used to
>generate the last overwrite-and-verify pass from the NAVSO P5239-26
>overwriting routines means that any command to Sanitize a file per
>DOD5220.22-M produces a keystream generator test output to disk of
>that size.

Isn't that kind of risky?  Because of the design of the X9.17 generator
(which I'm not a great fan of for this reason), it means you end up revealing 
vast amounts of internal state to an attacker.  Admittedly an attacker will be
up against triple DES to get the generator key, but providing hundreds of 
thousands of plaintext/ciphertext pairs seems risky (you can for example scan 
memory for blocks of high entropy which produce the given ciphertext from the 
given plaintext via 3DES).  I'd at least pass the results through SHA-1 on the 
way out.

Peter.


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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Feb 2000 01:14:37 GMT

James Felling <[EMAIL PROTECTED]> wrote:

: Wouldn't a better scheme be:
: pass 1: compress with compression X
:         2: encrypt with cypher A using key 1  in a chained mode starting at
: "middle" of file (treating file as a  ring buffer)
:         3: encrypt with cypher B using key 2 in a chained mode that starts at
: begining of file
:         4: encrypt with cypher C using key 3 in a chained mode starting at
: "middle" of file (treating file as a  ring buffer)
:        ( 5: compress with  compression Y)

: Where cypher's A,B, and C are different cyphers, and X and Y good
: compressors.(X is good for compressing whatever is expected as  input, and Y
: if used is a good general purpose compressor). middle is defined in the spec.

: Reasoning. [snip]

: chaining will diffuse the data through the file in a fairly efficient manner,
: and in theory every block will have a chance to affect all others.

I don't think you have any reverse diffusion present - or rather not
any that goes beyond block boundaries.  I'm /assuming/ that the
compressors mainly parse the file from the first byte forwards in
writing this.

Getting reverse diffusion was the reason why DS reverses the file and
applies compression again.

I don't see much point in starting encryption in the middle of the file,
and treating the file as a "ring".

This *doesn't* have much effect effect in terms of diffusing the
information necessary to decrypt the file from the last half of the file
to the first half - due to the error recovery property of the chaining
mode used, a matter which DS has discussed in this forum ad-nauseum.

: The final compression is im my opinion unnecessary, but may be done to save
: bandwidth.

It will probably /increase/ bandwidth.  Attempts to compress "random"
files usually increase their size slightly.  This is true even when a
"good general-purpose compressor" is used.

[appended old message fragment follows]

: Tim Tyler wrote:

[snip]

:> To my ears, the description quoted at the top sounds like an extremely
:> garbled version of DS's recommendation of a method get diffusion of
:> plaintext information through the entire message by applying adaptive
:> compression programs "in both directions" through the file - in the
:> absence of any better whole-message diffusion scheme.
:>
:> Such "compression in both directions" is mainly designed to produce
:> diffusion of the plaintext information through the file. [...]

[snip rest]
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

Taxes are not levied for the benefit of the taxed.

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

From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: new standart for encryption software...
Date: 11 Feb 2000 01:43:03 GMT



"finecrypt" <[EMAIL PROTECTED]> writes:

>Among pseudo-random values that has been retrieved during key generation 
>(and I specified these values in my post ) there is such values as 
>milliseconds since Windows started, types of events in input queue, 1 ms 
>time for last message and so on. These values permanently changing during 
>key generation. .

[...]

>Entire cycle of key generation on PIII takes less than 0,1 sec.

OK, to summarise:

1. You're using some millisecond-granularity counters[0].
2. You're doing 1000 polls.
3. These polls complete in 100ms.

The rest is left as an exercise for the reader.

Peter.

[0] Actually some or possibly all of these are very likely to only have 55ms 
    granularity even if the docs say 1ms.


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


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