Cryptography-Digest Digest #681, Volume #11 Mon, 1 May 00 19:13:01 EDT
Contents:
Re: Joystick as RNG (Mok-Kong Shen)
Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (jungle)
Silly way of generating randm numbers? (JCA)
Re: Magnetic Remenance on hard drives. (Thor Arne Johansen)
Re: Joystick as RNG (Tom St Denis)
Re: Another naive question (James Felling)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (James Felling)
Re: factor large composite (Stanley Chow)
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (James Felling)
Re: mod function? (Mok-Kong Shen)
Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (James Felling)
Re: Silly way of generating randm numbers? (Mok-Kong Shen)
Re: Diff analysis (Baruch Even)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Joystick as RNG
Date: Tue, 02 May 2000 00:19:35 +0200
"NFN NMI L. a.k.a. S.T.L." wrote:
> Gravis gamepad? Take a look at the data coming from that puppy. While it's a
> great joystick (I use it myself), it isn't like a normal joystick. It can only
> register 8 directions, good for games, bad for crypto. Unless you have some
> funky new version.
>
I think Tom St Denis is very fond of experimenting with quite a lot of
stuffs. This is not bad though, since many discoveries have stemmed
from rather arbitrary experiments.
M. K. Shen
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss
Subject: Re: S/MIME + Netscape v47 serious problem in symmetric encryption ...
Date: Mon, 01 May 2000 18:11:04 -0400
when I'm sending to myself [ encrypted ],
received message reports ALL THE TIME 3DES / 168 bits applied cipher
[ despite, I never selected it in my configuration ]
in netscape, my 1 [ ONE ] only selected cipher is RC2 / 128 bits ]
the other people who are reporting to me that they selected cipher is
RC2 / 128 bits, in my place, they e-mail's are reporting RC2 / 40 bits ONLY ...
Travis Farral wrote:
>
> It just seems odd that the issue seems to exist in both the Outlook & Netscape mail
> clients. Two other people I know of experience the same issue with Outlook. So far
>I
> don't know anyone who has actually been able to produce a verified 128 bit encrypted
>mail
> using digital certificates. I simply stuck with PGP and quit using the Verisign
>method
> as I was unsure what was happening behind the scenes.
>
> Anyway, it would be interesting to find out why it keeps reporting only 40-bit
> encryption.
>
> -Travis
>
> jungle wrote:
>
> > user error [ my error ] ? NO ...
> > windows error ? the certificate is handled by Netscape & not by win95 ... in my
> > understanding ...
> >
> > Travis Farral wrote:
> > >
> > > I have seen both of these examples as well using Outlook Express 5.00 w/128 bit
> > > security and a Verisign digital certificate on Windows 2000 Professional.
>Outlook
> > > 2000 appears to perform the same on the same machine with the same certificate.
>Is
> > > this a problem with Windows and not necessarily with the mail clients? Or is it
> > > simply user error and something isn't set right? I beat my head over this
>several
> > > weeks ago and finally gave into the fact that whatever encryption method you set
>it
> > > for isn't necessarily what you will get.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Silly way of generating randm numbers?
Date: Mon, 01 May 2000 15:13:38 -0700
Reminded the other day about Shanks and his mistake when computing
pi to more
than 700 decimal places (apparently only the 500-odd first ones are
correct) I
couldn't help wondering if this might provide a way to generate strings
of random
integers:
Start the computation of pi to some given precision and at some
(pseudo)
randomly chosen step make a deliberate arithmetic mistake a la Shanks.
The digits
generated from that point onwards are of course not part of pi any more
(at least not
in that particular position), and could in principle be used as random
digits.
Now it is not clear that this procedure might not lead to a
trivially predictable
strings of digits (short period strings) but it is true that Shanks came
up with
something that looks convincingly random all right.
Is this completely preposterous?
------------------------------
From: Thor Arne Johansen <[EMAIL PROTECTED]>
Subject: Re: Magnetic Remenance on hard drives.
Date: Tue, 02 May 2000 01:01:51 +0200
"NFN NMI L. a.k.a. S.T.L." wrote:
>
> Symantec offers data recovery services. The person who posted that such
> services are not commercially available is a [insert flame here].
>
Well, at least you did not spell out the flame...
I never said that data recovery is not offered commercially. I said that
recovery of _overwritten_ data is not commercially available.
Since I work for a data recovery company I would be very interested in
knowing about equipment/methods or even theories about how to recover
overwritten data.
I am familiar with Peter Gutman's paper, and various high resolution
imaging techniques. (E.g. based on MFM or the Kerr Effect).
When I say overwritten data, I mean overwritten data. It is perfectly
clear that data that is _not_ overwritten due to track mis-registration
(TMR) can be recovered. A one time overwrite can certainly leave small
randomly placed fractions of the old track intact after overwriting.
However which sections of a track that will be available (not
overwritten) will be random since TMR is caused mainly from
non-repeatable spinde runout (NRR) and turbulence. Overwriting a track
several times will decrease the probability that a given portion of a
track was not overwritten.
Aside from the TMR issue, I still claim that there are no plausible
theories (in the public) of how to get from the magnetized regions, to
the data that used to be there (before beeing overwritten).
Such theories and descriptions would have to address the heavy
non-linear distortions introduced by the overwrite process, as well as
the dramatic drop in S/N ratio.
BR,
Thor A. Johansen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Joystick as RNG
Date: Mon, 01 May 2000 22:26:02 GMT
"NFN NMI L. a.k.a. S.T.L." wrote:
>
> Gravis gamepad? Take a look at the data coming from that puppy. While it's a
> great joystick (I use it myself), it isn't like a normal joystick. It can only
> register 8 directions, good for games, bad for crypto. Unless you have some
> funky new version.
I don't actually move the thing. I just leave it sit there and it goes
on it's on.
I find there is too much correlation to use it properly as a rng... too
bad.
Tom
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Another naive question
Date: Mon, 01 May 2000 17:26:04 -0500
Joseph Ashwood wrote:
> In general I'm inclined to say that the difficulty will be
> the same, but if E is chosen properly, the difficulty should
> increase. Honestly this is in terms of analysis difficulty
> this is equivalent to multiple encryption, which is a
> double-edged sword.
> Joe
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > Suppose one has a block cipher and two plaintexts of equal
> length
> > with
> >
> > C1 = E(P1)
> >
> > C2 = E(P2)
> >
> > Let
> >
> > C3 = C1 xor P2
> >
> > Assuming that the opponent has no knowledge of P1, is C3
> easier
> > or more difficult to analyze than C2 in general? Thanks.
> >
> > M. K. Shen
> >
This all depends upon E, and to some degree your P1. What you are
doing in this case is using the block cypher as a form of stream
cypher. If it generates good nearly random output C3 may be more
difficult to analize than C2, it may not be ( it all depends upon how E
breaks down -- if it is a better RNG , then C3, if it is a better block
cypher C2.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Mon, 01 May 2000 17:36:04 -0500
Tom St Denis wrote:
> Richard Heathfield wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > "Douglas A. Gwyn" wrote:
> > > >
> > > > Tom St Denis wrote:
> > > > > 3) Why perms of 0-9? You waste alot of space that way, why not 0-16 or
> > > > > 0-255?
> > > >
> > > > Yes, that is an obvious question that deserves an answer.
> > > > I have my own theory as to the *real* answer to that,
> > > > but let's use this question as a "litmus test" to see
> > > > whether OAP-L3's author sincerely wants us to understand
> > > > his system.
> > >
> > <snip>
> > >
> > > I am not sure if it is in the Help Files but it is in the patent
> > > application that there is no restriction on number base. Base 16
> > > could be used. The problem with Base 16 is that there would then be
> > > 16! possible unique permutations of the hex digits 0 - 15 and current
> > > pc computers are too slow to take advantage of the greater security
> > > Base 16 would provide. Also storage requirements may pose a problem,
> > > etc.
> > >
> >
> > [Disclaimer: I'm not a cryptologist.]
> >
> > I find it surprising that anyone can attempt to defend their
> > cryptographic technique when they don't understand about
> > security-in-the-key, or killfiles (Mr Szopa's killfile seems to work
> > more as a slightly-woundedfile) - but when they don't even understand
> > about storage requirements, surprise is no longer adequate and, like Mr
> > Adams, I am forced to resort to astonishment.
> >
> > Let's deal with the "storage requirements problem" first. And it looks
> > like we'll have to go back to first principles to do so.
> >
> > Most modern computers use lots and lots of bits, each of which can store
> > one of two values, 0 or 1.
> >
> > A combination of four bits is required, therefore, to store the digits 0
> > through 9.
> >
> > 0000 - 0 0001 - 1
> > 0010 - 2 0011 - 3
> > 0100 - 4 0101 - 5
> > 0110 - 6 0111 - 7
> > 1000 - 8 1001 - 9
> >
> > The numbers 0 through 99 can thus be represented in one 8-bit byte.
> > (Bytes need not be 8 bits, but I see no need to go down that road right
> > now.) To store a value such as 16304791, then, we need 4 bytes. This
> > encoding system (or a slight modification of it) is sometimes known as
> > binary coded decimal.
> >
> > If we extend our numbering sequence to encompass the hexits A, B, C, D,
> > E, F to represent 10 through 15 decimal, we can extend our 4-bit table
> > to include
> >
> > 1010 - A 1011 - B
> > 1100 - C 1101 - D
> > 1110 - E 1111 - F
> >
> > We can now store values 0 through 255 in one 8-bit byte. Much more
> > efficient. We can now store 16304791 in hexadecimal as F8CA97, giving a
> > storage requirement of only 3 bytes.
>
> When you do something like
>
> long a = 16304791;
>
> You need not convert it to hex to store it. My complaint about the
> waste of space is that a permutation is normally stored as
>
> int perm[10] = { ... }
>
> and you store them serially (even as 4 bits you are wasting space).
> Also note that not all numbers between 0 and 2^24 - 1 (3 bytes) are
> possible so again you are wasting space...
>
> My point was why doesn't he use a permutation of a power of two and not
> waste space? Like 0..7 or 0..15 ?
I have less probelm with that than with the fact that his shuffling opps are less
efficient thatn they should be and fail to employ any offsets as to starting point
that would enhance their security versus certian forms of attacks.( True I cannot
beat the system as "properly implemented", but proper implementation is a truly
ridiculous amount of work for what 5 minutes with any other crypto program gives me.
-- and I am not certian that even then he is as secure as he should be.
> <snip for brevity -- good stuff unrelated to my point>
>
> Or just use. Why do you have to buy good crypto programs? If you have
> enough time on your hands you can even write your own.
>
> Mr Szopa has some thinking todo about making his algorithm(s) not only
> public but efficient.
>
Seconded.
>
> Tom
> --
> Want your academic website listed on a free websearch engine? Then
> please check out http://tomstdenis.n3.net/search.html, it's entirely
> free
> and there are no advertisements.
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Mon, 01 May 2000 22:46:21 GMT
This is a multi-part message in MIME format.
==============4847FD823683A2B6CD904BFE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Diet NSA wrote:
>
> Theoretically, the fastest known method for factoring large
> numbers is still Shor's algorithm (or a modification of it).
To be pedantic, a giant table look-up is faster (in Rubic's cube
literature, this is refered to as God's Algorithm). I think by
most measures of "realistic", this is currently more realistic
than Shor's algorithm.
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
==============4847FD823683A2B6CD904BFE
Content-Type: text/x-vcard; charset=us-ascii;
name="stanley.chow.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Stanley Chow
Content-Disposition: attachment;
filename="stanley.chow.vcf"
begin:vcard
n:Chow;Stanley
tel;fax:(613) 271-9447
tel;work:(613) 271-9446 x 223
x-mozilla-html:FALSE
url:http:/www.cloakware.com
org:Cloakware Corp.
adr:;;260 Hearst way, suite 311;Kanata;Ontario;K2L 3H1;Canada
version:2.1
email;internet:[EMAIL PROTECTED]
title:VP Engineering
x-mozilla-cpt:;0
fn:Stanley Chow
end:vcard
==============4847FD823683A2B6CD904BFE==
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Mon, 01 May 2000 17:43:30 -0500
Anthony Stephen Szopa wrote:
> Tom St Denis wrote:
> >
> > Richard Heathfield wrote:
> > > unsigned char num[] = { 0x16, 0x30, 0x47, 0x91 }; /* binary coded
> > > decimal (almost!) - wastes 6 combinations per nybble */
> > >
> > > as opposed to
> > >
> > > unsigned char num[] - { 0xF8, 0xCA, 0x97 }; which is clearly more
> > > efficient, as it uses all the bits available to it.
> > >
> > > So perhaps we're in violent agreement?
> >
> > No since not all combinations of 3 byte values are possible you are
> > still wasting space. That was my point.
> >
> > >
> > > > > If we have two cryptography applications, one of which uses its memory
> > > > > efficiently, runs on my PII/400 at an acceptable speed, and offers me
> > > > > reliable security, and the other which doesn't use its memory
> > > > > efficiently, runs on my 400 MHz box at a speed which even its author
> > > > > says is far too slow, and is based on source code which has not been
> > > > > published and therefore has not had the chance to be validated by the
> > > > > cryptographic community - thus making its security untrustworthy - which
> > > > > application do you think anyone with a brain will buy?
> > > >
> > > > Or just use. Why do you have to buy good crypto programs?
> > >
> > > I agree entirely. Just roll your own...
> > >
> > > > If you have enough time on your hands you can even write your own.
> > >
> > > Ah, I don't have enough time on my hands. But I'm trying to write my own
> > > anyway <g>. Unfortunately, I'm too inexperienced in cryptanalysis to
> > > perform serious cryptanalytic attacks on my own code, let alone other
> > > people's. (I've cracked a couple of 'unbreakable' algorithms presented
> > > to me by other would-be cryptographers, but these were only 'kid-sister
> > > unbreakable', of course.)
> >
> > Well it's one thing to take already developed and analyzed algorithms
> > and stick it together, and it's another thing *entirely* to invent your
> > own ciphers at the same time. If you want a 5kb file crypto program
> > just take RC4 and a hash (say md2) and write a small program (I have
> > done it more then once.... :)).
> >
> > > >
> > > > Mr Szopa has some thinking todo about making his algorithm(s) not only
> > > > public but efficient.
> > > >
> > >
> > > Possibly, but that's not his main problem. He has some really serious
> > > thinking to do about his ability to deal with fellow professionals in a
> > > professional way. It seems that anyone who dares take issue with him is
> > > instantly killfiled - in a mysterious and magical process which allows
> > > Mr Szopa to read their posts anyway, presumably so that he can killfile
> > > them again, and again, and again.
> > >
> > > When he learns to talk to grown-ups as if they are grown-ups, I suspect
> > > he can look forward to some excellent help from the heavyweight computer
> > > scientists in this newsgroup (Doug Gwyn and so on) in making his
> > > algorithm efficient.
> >
> > Well the pros are really turned off from him, so at best he will have to
> > deal with the-less-than-amateurish people like You and I....
> >
> > Tom
> > --
> > Want your academic website listed on a free websearch engine? Then
> > please check out http://tomstdenis.n3.net/search.html, it's entirely
> > free
> > and there are no advertisements.
>
> You say writing encryption software is easy. You've done it? Just
> do this and just do that?
>
> Who wants just "adequate" or "okay" encryption software? We've got
> plenty of that already.
>
> The gold medal goes to creating unbreakable encryption... And
> creating it first.
Anyone can create software that is as "unbreakable" as yours. In a few days with a
decent compiler. Your product wouldn't even take an honnorable mention.
>
>
> I claim to have created unbreakable encryption software.
Excellent choice of words -- true enough given enough effort, but in any usable
aplication........?
> And I
> can provide anyone with the software to see for themselves. The
> Help Files describe OAP-L3, and the Theory and Processes Help Files
> prove my claim.
They "prove" nothing of the sort. This is like saying that the existence of the
Princess Bride (which claims to be a 'good parts' version of annother novel) proves
that that other volume exists. All it does is provide some evidence possibly
supporting our claim, there is nothing there that is conclusive ( or even very
readable).
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: mod function?
Date: Tue, 02 May 2000 00:58:06 +0200
Anton Stiglic wrote:
> The "three argument mod" (as you call it) is very much used in logic theory
> and algebra theory. It is the boolean version of the function. It is the
> binary relation (f_p(a,b) = true if a = b mod p) that is used to define the
> equivalence relation. Now, for what Bob said about it being the definition
Just as a point of interest and curiosity, could you name a book of
mathematical logic or algebra where such extensive use of the 3 argument
mod is to be found? The few books about logic and algebra that I happen
to have in my personal library don't have such uses at all. Thanks in
advance.
M. K. Shen
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss
Subject: Re: S/MIME + Netscape v47 serious problem in symmetric encryption ...
Date: Mon, 01 May 2000 17:55:57 -0500
Maybe a glitch in Microsofts Crypto API -- Do both of them use that?
Travis Farral wrote:
> It just seems odd that the issue seems to exist in both the Outlook & Netscape mail
> clients. Two other people I know of experience the same issue with Outlook. So far
>I
> don't know anyone who has actually been able to produce a verified 128 bit encrypted
>mail
> using digital certificates. I simply stuck with PGP and quit using the Verisign
>method
> as I was unsure what was happening behind the scenes.
>
> Anyway, it would be interesting to find out why it keeps reporting only 40-bit
> encryption.
>
> -Travis
>
> jungle wrote:
>
> > user error [ my error ] ? NO ...
> > windows error ? the certificate is handled by Netscape & not by win95 ... in my
> > understanding ...
> >
> > Travis Farral wrote:
> > >
> > > I have seen both of these examples as well using Outlook Express 5.00 w/128 bit
> > > security and a Verisign digital certificate on Windows 2000 Professional.
>Outlook
> > > 2000 appears to perform the same on the same machine with the same certificate.
>Is
> > > this a problem with Windows and not necessarily with the mail clients? Or is it
> > > simply user error and something isn't set right? I beat my head over this
>several
> > > weeks ago and finally gave into the fact that whatever encryption method you set
>it
> > > for isn't necessarily what you will get.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Silly way of generating randm numbers?
Date: Tue, 02 May 2000 01:09:03 +0200
JCA wrote:
>
> Start the computation of pi to some given precision and at some
> (pseudo)
> randomly chosen step make a deliberate arithmetic mistake a la Shanks.
> The digits
> generated from that point onwards are of course not part of pi any more
> (at least not
> in that particular position), and could in principle be used as random
> digits.
Could you elaborate your phrase 'could in principle be used as random
digits' a bit? What is exactly your definition of randomness? In sci.crypt
there had been much discussions on that. I am yet not aware of a
practical method of testing true randomness according to a definition
that is both rigorous and satisfying. Are the digits of the true Pi sequence
already proved to be 'random'? Thanks.
M. K. Shen
------------------------------
From: Baruch Even <[EMAIL PROTECTED]>
Subject: Re: Diff analysis
Date: Tue, 02 May 2000 00:11:56 +0200
I understand that you want to create the difference table for a certain
S-Box in a DES-like cipher.
The difference table measures how many times for a specific input difference
(i.e. x^y) you get a specific output difference (i.e. S[x]^S[y]).
I really do not understand what you do with S[x xor y], as we do not
measure that.
Basically you loop over all possible inputs of x and y and do:
table[x^y][S[x]^S[y]]++;
In article <[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
> Ok I just looked at "Differential Cryptanalysis of Des-like
> cryptosystems" and let's see if I got the xor-diff counting right...
>
> m = size of input in bits
> n = size of output in bits
> a = 2^m - 1
> b = 2^n - 1
> DT[a+1][b+1] = { 0 }
> S[] = the m by n sbox
>
> for x = 0 to a
> for y = 0 to b
> DT[x xor y][S[x] xor S[x xor y]] += 1
>
> Which says add one to the row 'x xor y' and column xor 'S[x] xor S[x xor
> y]'
>
------------------------------
** 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
******************************
