Cryptography-Digest Digest #702, Volume #11 Thu, 4 May 00 07:13:00 EDT
Contents:
Re: Tempest Attacks with EMF Radiation (Mok-Kong Shen)
Re: Interleaving for block encryption (Mok-Kong Shen)
Re: KRYPTOS Something new ? (Jim Gillogly)
Re: KRYPTOS Something new ? (Mok-Kong Shen)
Re: mod function? (Mark Wooding)
Re: Tempest Attacks with EMF Radiation (Richard Herring)
Re: Fixed: Sboxgen tool (Tom St Denis)
Sample Output from SBOXGEN (Tom St Denis)
Re: Diff analysis (Tom St Denis)
Re: Fixed: Sboxgen tool (Tim Tyler)
Re: Fixed: Sboxgen tool (Tom St Denis)
Re: Deciphering Playfair (long) ("Colin Barker")
Re: mod function? (Tom St Denis)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
("Neon Bunny")
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
("Neon Bunny")
Re: GPS encryption turned off (Nogami)
Re: GPS encryption turned off (Francois Grieu)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tempest Attacks with EMF Radiation
Date: Thu, 04 May 2000 10:31:07 +0200
Woody Brison wrote:
> We had a guy at Ford Aerospace that brought in one of these
> things, it looked like a little block with a rod sticking
> up out of it. At the top of the rod was a ball of what
> looked like steel wool, only of copper color. He said it
> produced good ions and made everybody around it happy. He
> sure was a positive upbeat guy. But when I first saw this
> thing on his desk I had no idea what it was, I was fingering
> the copper wool and wondering; then I walked over and took
> ahold of the doorknob and about got knocked on my butt. So
> now they're selling them as EMF blockers. Huh.
The device you described seems to require very little energy. Can
that be true?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interleaving for block encryption
Date: Thu, 04 May 2000 10:46:06 +0200
"Douglas A. Gwyn" wrote:
> But any block cipher worth using is not going to be cracked using
> key-guessing methods. Historically, systems have combined two
> forms of encryption such as codebook+polyalphabetic_substitution,
> and cryptanalysts have found ways to more or less routinely strip
> off one of the layers of encryption so that they could work on the
> other. In the context of modern block ciphers, any extra key bits
> would be better used in a single integrated encipherment than
> split between two orthogonal encipherments.
You are right. However, if one worries that a given block cipher might
be brute-forced, using a simple cipher to preprocess does seem to
help. It is admittedly difficult to assess in given constallations the
improvement in quantitative terms.
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: KRYPTOS Something new ?
Date: Thu, 04 May 2000 08:46:39 +0000
"Douglas A. Gwyn" wrote:
>
> Collomb wrote:
> > If, after one year past, these 97 characters were still not
> > deciphered, it is possible to doubt the accuracy of the work
> > of these three decipherers.
>
> Not when the sculptor and the cryptographer who created the
> cipher text have verified the correctness of that work!
>
> 97 characters is not much material to work with if the
> encipherment is (as suggested by the evidence) in a system
> somewhat harder than the ones used in the first three parts.
> Most likely a breakthrough will require a lucky guess about
> the method and one or more keywords used in constructing
> the enciphering alphabets.
As one of the "three decipherers", I agree with this.
Another correction to the first remark: it's now about eight years
past the first break of all but the last 97 characters, and two
years past the second break. The three breaks were independent,
having taken place in disjoint security regimes.
--
Jim Gillogly
14 Thrimidge S.R. 2000, 08:43
12.19.7.3.4, 3 Kan 7 Uo, First Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: KRYPTOS Something new ?
Date: Thu, 04 May 2000 10:56:47 +0200
Collomb wrote:
>
> I offer on my website :
> http://calvaweb.calvacom.fr/collomb /
> a complete and original solution of entire Kryptos, which precisely is
> based on the forms.
Could some experts who have previously solved a large part of the
cipher comment on the correctness of this complete solution?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: mod function?
Date: 4 May 2000 09:47:09 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> A mathematician would be more likely to use a notation like:
>
> 8 = 5 modulo 3
>
> Where the "modulo 3" part is read as an alteration to the equality
> operator.
Here, ASCII is limiting us. The usual notation I've seen is more like
`a = b (mod n)' where `=' is really the three line `equivalent to'
relation. Or, in TeX, $a \equiv b \pmod{n}$. And the usual definition
I've seen is that we say $a \equiv b \pmod{n}$ iff there exists an
integer $k$ such that $a = b + k n$.
[1] Note that standard TeX puts too much space before the `(mod n)' in
standard maths mode. It looks OK in display maths, though.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Tempest Attacks with EMF Radiation
Date: 4 May 2000 10:08:58 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Diet NSA
([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>, "Trevor L. Jackson, III"
> <[EMAIL PROTECTED]> wrote:
> >
> >nature of ions and of EMF radiation. EMF stands for
> ElectroMotive Force.
> Actually, "EMF" stands for electric & magnetic field or
> electromagnetic field.
Electromotive force, or electromagnetic field - which means the
far-field component in which the electric and magnetic fields are
perpendicular to each other and the direction of propagation,
and in the constant ratio Z_0, and the intensity falls off with
an inverse-square law.
I've never seen it used for "electric & magnetic field" - what would
be the point?
>(Within the range "ELF"- extremely low
> frequency, electric & magnetic fields are not coupled like they
> are at higher frequencies).
Up to a point, and only if by "coupled" you mean what I have written
above about the far-field component.
The distinction is between the near (static), intermediate (induction)
and far (radiation) zones, which depend on the ratios of source size,
distance and wavelength.
As the frequency decreases, the size of the nearer zones increases, so
the far-field behaviour is only dominant at greater distances. Nevertheless
it still exists.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Fixed: Sboxgen tool
Date: Thu, 04 May 2000 10:14:57 GMT
Terry Ritter wrote:
>
> On Thu, 04 May 2000 02:13:35 GMT, in <[EMAIL PROTECTED]>,
> in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >Tim Tyler wrote:
> >>
> >> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >>
> >> : [...] The SAC test actually works now. I misunderstood the changed bit
> >> : count must equal have the output size, it's suppose to be at least
> >> : half.
> >>
> >> This doesn't sound /quite/ right to my ears:
> >>
> >> SAC says that if you flip a particular input bit, half the output bits
> >> flip - *if you consider all possible input vectors*.
> >
> >I do a double loop
> >
> >for x = 0 to n-1
> > for y = 0 to log2(n)
> > if HT[f(x) xor f(x xor (1 << y))] < log2(n)/2
> > return non_sac.
> >
> >> In other words, the /probability/ of each output bit flipping, on flipping
> >> any input bit, is 1/2.
> >
> >Well I think you can get by checking that at least half the bits change
> >when one input changes.
>
> No, that is not right. The desired situation is to have *about* half
> the bits change, not *at* *least* *half*.
What is wrong when more then half change?
Ton
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Sample Output from SBOXGEN
Date: Thu, 04 May 2000 10:21:19 GMT
I made some GOST-like sboxes using my tool (now that I fixed the
sac_test (*)). The sboxes can be found at http://24.42.86.123/gostbox.c
and the analysis output can be found at http://24.42.86.123/gostbox.txt.
They are designed to be linearly bounded to p = 1/2 +- 1/4, and the
strongest differential trait (xor-pair) occurs 1/4th of the time.
Tom
[*] Does SAC mean only half the bits change when an input changes or *at
least* half the bits change? I noticed one of the rules for DES sboxes
is that 'at least' half the bits have to change...
--
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Diff analysis
Date: Thu, 04 May 2000 10:29:23 GMT
Baruch Even wrote:
>
> 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]]++;
(old post but resolve the issue...)
I do this in the new sboxgen program.
The only problem is now the def of SAC, is it exactly half the bits have
to change or at least.....
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Fixed: Sboxgen tool
Reply-To: [EMAIL PROTECTED]
Date: Thu, 4 May 2000 09:45:46 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : [...] I misunderstood the changed bit count must equal have the
:> : output size, it's suppose to be at least half.
:>
:> This doesn't sound /quite/ right to my ears:
:>
:> SAC says that if you flip a particular input bit, half the output bits
:> flip - *if you consider all possible input vectors*.
: I do a double loop
: for x = 0 to n-1
: for y = 0 to log2(n)
: if HT[f(x) xor f(x xor (1 << y))] < log2(n)/2
: return non_sac.
I believe this code will identify some functions which have SAC as not
having it - and mis-identify some which have p > 1/2 as exhibiting SAC.
:> In other words, the /probability/ of each output bit flipping, on flipping
:> any input bit, is 1/2.
: Well I think you can get by checking that at least half the bits change
: when one input changes. [...]
That will give you /an/ avalanche criterion of sorts - but not the one
normally associated with "SAC".
There are various ways of extending and generalising the SAC - some of
which are described at the start of the paper at
http://www.iicm.edu/jucs_1_5/gac_the_criterion_for - but yours does not
appear to be listed among them.
There are SAC definitions available on the web. See the third paper at:
http://sciences.aum.edu/~stanpan/math_work.html
("Bounds on the number of functions satisfying the SAC"), for example.
To quote from that: ``[a boolean function] is said to satisfy the SAC
if complementing a single input bit results in changing the output bit
with a probability exactly one half.''
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Fixed: Sboxgen tool
Date: Thu, 04 May 2000 10:41:06 GMT
Tim Tyler wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> :> : [...] I misunderstood the changed bit count must equal have the
> :> : output size, it's suppose to be at least half.
> :>
> :> This doesn't sound /quite/ right to my ears:
> :>
> :> SAC says that if you flip a particular input bit, half the output bits
> :> flip - *if you consider all possible input vectors*.
>
> : I do a double loop
>
> : for x = 0 to n-1
> : for y = 0 to log2(n)
> : if HT[f(x) xor f(x xor (1 << y))] < log2(n)/2
> : return non_sac.
>
> I believe this code will identify some functions which have SAC as not
> having it - and mis-identify some which have p > 1/2 as exhibiting SAC.
This function returns true (not very often) when a single input change
changes *at least* half the output bits over all possible inputs. The
sbox has to satisfy at least SAC partially (unless SAC allows more then
half). I.e the ouput change is high.
> :> In other words, the /probability/ of each output bit flipping, on flipping
> :> any input bit, is 1/2.
>
> : Well I think you can get by checking that at least half the bits change
> : when one input changes. [...]
>
> That will give you /an/ avalanche criterion of sorts - but not the one
> normally associated with "SAC".
>
> There are various ways of extending and generalising the SAC - some of
> which are described at the start of the paper at
> http://www.iicm.edu/jucs_1_5/gac_the_criterion_for - but yours does not
> appear to be listed among them.
>
> There are SAC definitions available on the web. See the third paper at:
>
> http://sciences.aum.edu/~stanpan/math_work.html
>
> ("Bounds on the number of functions satisfying the SAC"), for example.
>
> To quote from that: ``[a boolean function] is said to satisfy the SAC
> if complementing a single input bit results in changing the output bit
> with a probability exactly one half.''
Hmm I have to change it around then. However if there is a strong
correlation between flipping an input bit and the output it's linear.
So making the function non-linear should help that. If you think about
it, if one output bit is strongly correlated to flipping a particular
input bit, then that output bit is linear (or closer to linear).
...
So if I get it right, changing a single input bit will change each
output bit with a prob 1/2, which is essentially half the output bits.
So you should expect *exactly* log2(n)/2 bits to change?
Tom
------------------------------
From: "Colin Barker" <[EMAIL PROTECTED]>
Subject: Re: Deciphering Playfair (long)
Date: Thu, 4 May 2000 12:53:35 +0200
Michael Jarrells a écrit dans le message
<[EMAIL PROTECTED]>...
>William Rowden wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] wrote:
>> > Message 2:
>> > Ciphertext:
>> >
>> FWFUIVGXVCZOWZYLEOXPIAPDUGNMLOAYXNQLQLTDNLYWXTOWXLYFVOUTZIAYEYWIYQOLYQV
>>
>> Is there a typo in this post? Or does the ciphertext really have an odd
>> number (71) of letters?
>>
[snip]
>
>This is the ciphertext as given. There is a possibility that the
>original ciphertext has a character in the middle of the repeating QLQL,
>but this can not be confirmed. In my copy it looks like it may be an X,
No, it should be QLAQL. And as Jim Gillogly has pointed out, there are other
typos/incorrect encoding as well.
>but I don't know for sure.
>
>Thanks for the help. Good luck.
>
[snip]
Colin
E-mail: mailto:[EMAIL PROTECTED]
Internet: http://perso.wanadoo.fr/colin.barker
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: mod function?
Date: Thu, 04 May 2000 10:55:04 GMT
Mark Wooding wrote:
>
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > A mathematician would be more likely to use a notation like:
> >
> > 8 = 5 modulo 3
> >
> > Where the "modulo 3" part is read as an alteration to the equality
> > operator.
>
> Here, ASCII is limiting us. The usual notation I've seen is more like
> `a = b (mod n)' where `=' is really the three line `equivalent to'
> relation. Or, in TeX, $a \equiv b \pmod{n}$. And the usual definition
> I've seen is that we say $a \equiv b \pmod{n}$ iff there exists an
> integer $k$ such that $a = b + k n$.
>
> [1] Note that standard TeX puts too much space before the `(mod n)' in
> standard maths mode. It looks OK in display maths, though.
>
> -- [mdw]
I thought a = b (mod n), meant 'a is congruent to b modulo n'?
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: "Neon Bunny" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the
net"
Date: Wed, 3 May 2000 19:38:06 +0100
> ##############
> How are you going to alter the header if you're not using a remailer when
> the header is generated by the sever and not your PC?
> donoli.
> ##############
I think he's refering to the PGP header which is needed to conform to the
OpenPGP standard, as opposed to email headers which are a nessicary evil.
NeonBunny
--
Web: http://bunnybox.jml.net
PGP: http://bunnybox.jml.net/neonbunny.asc
------------------------------
From: "Neon Bunny" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the
net"
Date: Wed, 3 May 2000 19:40:29 +0100
<SNIP>
> I believe the data part of a pgp file is indistinguishable from white
> noise so if the software was altered a little to encrypt the header as
> well the authorities couldn't tell the difference between your code and an
> analogue recording of white noise..?
I think there was an article on HNN a LONG time ago which refered to methods
of finding encrypted data, aparently the data is sooo random that it's over
random and thus it sticks out like a sore thumb compared to the
repetativeness of most file types (BMP a perfect example). maybe
implementing some padding into a stenography program would be the way to go
(unless it's already been done!)
NeonBunny
--
Web: http://bunnybox.jml.net
PGP: http://bunnybox.jml.net/neonbunny.asc
------------------------------
From: Nogami <[EMAIL PROTECTED]>
Subject: Re: GPS encryption turned off
Date: Thu, 04 May 2000 03:58:49 -0700
On Wed, 03 May 2000 17:14:01 GMT, [EMAIL PROTECTED] (Doug Stell)
wrote:
>This is a very good and true point. Just imagine a commercial airliner
>crashing into the terminal, because it had been turned back on and the
>pilot wan't told.
If the pilot is within 50m of a terminal and is relying on GPS, I
don't want to be on the plane :P
At any rate, I read a press release on one of the major news sites the
other day saying that they would turn it back on for specific
locations if the situation warranted. Since there are quite a few GPS
satellites, I assume they could just re-scramble european coverage if
they wanted to, or North America, etc.
N.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: GPS encryption turned off
Date: Thu, 04 May 2000 13:07:35 +0200
[EMAIL PROTECTED] (Paul Rubin) wrote:
> Are you saying they're going to rekey all the receivers
> *except* the one left in the bar? How?!
A possible solution:
In each receiver store a permanent serial number j and a
rekeying key KRj derived from a master rekeying key KR
as KRj = ENC(KR,j). KRj is called a diversified key.
Have the global (!) current traffic key Kt used to encipher
the bulk of the traffic at a given time sent over the air as
multiple (j, Ktj = ENC(ENC(KR,j),Kt)) pairs, for those sole
receivers j you want to rekey (i.e. are white-listed).
Each receiver tests i in a received pair (i,Kti) against
it's own j, and if it matches decodes Kt = DEC(KRj,Ktj).
I whish my own company will not sue me for not checking this
is not patented :-)
Francois Grieu
------------------------------
** 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
******************************
