Cryptography-Digest Digest #666, Volume #12 Wed, 13 Sep 00 01:13:00 EDT
Contents:
Re: Intel's 1.13 MHZ chip ("Abyssmal_Unit_#3")
Re: question on the bible code ("Mikal 606")
Weak keys in RC4 (Patrick Schultz)
Re: ExCSS Source Code (Eric Smith)
Re: question on the bible code (Mr. Noel Yaki)
Re: Ciphertext as language (wtshaw)
Re: For the Gurus (wtshaw)
Crypto Related Pangrams (wtshaw)
Re: Bytes, octets, chars, and characters (Jerry Coffin)
Re: Getting Started, advice needed (FAQs , yes I read them) (David Hopwood)
Re: MAC (David Hopwood)
Re: SV: Intel's 1.13 MHZ chip (Greggy)
Re: SV: Intel's 1.13 MHZ chip (Greggy)
Re: Intel's 1.13 MHZ chip (Greggy)
Re: S.I. unit names, off-topic (was re Intel's 1.13 MHZ chip) (Greggy)
Re: Intel's 1.13 MHZ chip (Greggy)
Re: Intel's 1.13 MHZ chip (Greggy)
Re: Intel's 1.13 MHZ chip (Greggy)
Re: Getting Started, advice needed (FAQs , yes I read them) ("Scott Fluhrer")
Re: OutLook Express & SMIME (Greggy)
----------------------------------------------------------------------------
From: "Abyssmal_Unit_#3" <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Tue, 12 Sep 2000 20:10:02 -0400
yes, i believe you are correct regarding individual gate ratings. paralleling enough
of them and retaining coherent and usable
timing performance is a nighmare requiring device selection & that is another
hamstring. single die matching has nearly eliminated
this constraint entirely.
--
best regards,
hapticz
>X(sign here)____________________________________________<
John Savard wrote in message <[EMAIL PROTECTED]>...
|On Mon, 11 Sep 2000 13:18:54 -0400, "Abyssmal_Unit_#3"
|<[EMAIL PROTECTED]> wrote, in part:
|
|>MECL (Motorola Emitter Coupled Logic) architecture has been available for close to
|25 years with capability to perform at 1 to 2
gig
|>rates.
|
|Note, though, that ECL has much higher power consumption than CMOS,
|and supports much lower chip densities. (It's worse than bipolar,
|because it gains its speed by not driving its transistors to
|saturation.)
|
|Also, the 1 GHz speed of a microprocessor is for a machine cycle,
|which involves many elementary logic operations. The figure you quote
|may be the speed of individual NAND gates.
|
|John Savard
|http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Mikal 606" <[EMAIL PROTECTED]>
Crossposted-To: alt.bible.prophecy
Subject: Re: question on the bible code
Date: Tue, 12 Sep 2000 20:38:24 -0700
I understand many peoples deep desire to believe in this code.
But I ask you, what else does it add?Are you not already a believer?
Do you understand what I mean?
"TaoenChristo" <[EMAIL PROTECTED]> wrote in message
news:8pm1ig$a2f$[EMAIL PROTECTED]...
> In article <8pbko1$n2m$[EMAIL PROTECTED]>,
> "Mikal 606" <[EMAIL PROTECTED]> wrote:
> >
> > "John Kennedy" <[EMAIL PROTECTED]> wrote in message
> > news:9lcu5.20946$[EMAIL PROTECTED]...
> > >
> > > Then explain it.
> > > >Whats your interest in the matter?
> > > I think it's just interesting to see the names pop up....
> >
> > heres a good handling of ELS-
> > /
> > http://www.nctimes.net/~mark/fcodes/elsyesh.htm
> >
> >
>
> To explain why the ELS in the Bible is unique, you must understand, it
> is not just the occurance of words at certain skip lengths, as the
> author of this web page assumes. Even if the word Yeshua occured with
> cross (or whatever) in differant text, that shows nothing, but a neat
> coincidence... now find me ANY text that has the following words:
>
> Herod, Annas and Judas, ALL 12 diciples,"the Marys weep bitterly," "let
> him be crucified," "true Messiah" and "son of Mary"
>
> These in turn are intersected by hundreds of other similar ELSs.
>
It *has to be reconstructed* from the Hebrew alphabet and you can rebuild
all kinds of words when the original alphabet is missing vowels!
> All of these words and phrases are found intersecting Isaiah 52-53. The
> odds of all of the above phrases and words being found in ELS code, in
> only 2 chapters of one book of 66, would be somewhere around 1 in
> 3,408,749,015,176,240,000,000,000,000,000,000,000,000,000,000.
>
Really now!
> though you might be able to find Yeshua intersecting Christ or some
> other such combinations in other books, I find it to very unlikely that
> you will EVER find the combinations above in any other book anywhere!
>
> --
> Romans 1 20 For the invisible things of him from the creation of the
> world are clearly seen, being understood by the things that are made,
> even his eternal power and Godhead; so that they are without excuse:
>
>
Jeremiah 14:14
Then the LORD said unto me, The prophets prophesy lies in my name: I sent
them not, neither have I commanded them, neither spake unto them: they
prophesy unto you a false vision and divination, and a thing of nought, and
the deceit of their heart.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Patrick Schultz <[EMAIL PROTECTED]>
Subject: Weak keys in RC4
Date: Tue, 12 Sep 2000 18:20:14 -0700
I have seen it said several times that good implementations of RC4
discard the first 512 bytes generated. How does this compare with the
proposal for ciphersaber-2, that you run the entire state array mixing
loop multiple times? Are these two techniques both even addressing the
same problem? If they are, are there advantages/disadvantages to using
either one? The link for the ciphersaber faq, if anyone would like to
see it, is http://ciphersaber.gurus.com/faq.html.
-Patrick Schultz
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: 12 Sep 2000 18:24:48 -0700
[EMAIL PROTECTED] (Wim Lewis) writes:
> (And I *think* that DeCSS, etc., don't violate copyright law;
> they violate the Digital Millennium Copyright Act, which has
> "copyright" in its title but isn't strongly related to previously
> existing copyright law except that it benefits copyright holders.)
The DMCA is Public Law 105-304. It amends Title 17, United States Code.
By definition, anything in Title 17 is strongly related to copyright
law.
------------------------------
From: [EMAIL PROTECTED] (Mr. Noel Yaki)
Crossposted-To: alt.bible.prophecy
Subject: Re: question on the bible code
Date: Wed, 13 Sep 2000 02:02:53 GMT
"Mikal 606" <[EMAIL PROTECTED]> wrote:
>I understand many peoples deep desire to believe in this code.
>But I ask you, what else does it add?Are you not already a believer?
>Do you understand what I mean?
Proverbs 1:7 - The fear of the Lord is the beginning of knowledge; fools
despise wisdom and instruction.
Ecclesiastes 1:18 - For in much wisdom is much vexation, and he who
increases knowledge increases sorrow.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Ciphertext as language
Date: Tue, 12 Sep 2000 19:35:11 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > Tests show that as long a each consonent-vowel pair is said as indicated,
> > the characters can be easily written as heard. I suppose that I will see
> > what a speech synthesizer will do with them next.
>
> Maybe this is just because I am a foreigner, but I find
> 'x' to be disadvantageous for being used as vowel in the
> present context, i.e. I would perfer limiting to the
> set a,i,o,e,u. Then, I suppose the pairs of consonant-vowel
> would sound much like the Japanese alphabet, which means
> that these probably are good in their quality for voice
> transmission. (I know too little about Japanese. You have
> to check whether I said above is true.)
>
> M. K. Shen
In pronouncing any consonant letter, a vowel is used. X might be eks.
Consider that the same sound is used in hex, rex, mex, etc. In my use of
x as a vowel, these would be hx, rx, and me. Some might object to much
use of sx, but I am not a republican.
The A equivalent would be hax, racks, and max, but this strays from saying
eks. I have not objection to someone pronouncing these 78 differently
from me as long as they are distinctly 78 different ways. I worried about
this a length, not really, but came up with a prescription I liked a day
later. Gillogy suggests Italian sounds; I guess that pasta is OK.
--
Rats! (What Gov. Bush is apt to say the morning after the election)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: For the Gurus
Date: Tue, 12 Sep 2000 19:40:36 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> "root@localhost " wrote:
> >
> > If I wanted to design a simple manual system that I felt was very
> > difficult to crack, what historical system would you recommend I start
> > with and why?
>
> I am no guru, though not a pure beginner. I would suggest that
> you employ a transposition and a polyalphabetic substitution
> (with independent alphabets) and always use sufficiently long
> keys. If you like, you could add such stuffs like homophones.
> I can't discuss, though, the issue of strength (concerning your
> 'why'), for that topic is too difficult for my humble knowledge.
>
> M. K. Shen
I wonder what kinds of attacks that he wants to guard against, and how
dedicated the attacker is apt to be. This seems important. Some very
complicated systems fail to deliver when really tested in the real world.
--
Rats! (What Gov. Bush is apt to say the morning after the election)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Crypto Related Pangrams
Date: Tue, 12 Sep 2000 19:57:44 -0600
Here are some the pangram bug has caused me to write. Anyone else want to
write crypto related pangrams. Wth unlimited subject I have gotten many
in the 30's-40's size range, a few perhaps too offensive to actually post.
42) *Vexed xenophobes fear crypto's jazzy, quaint, works.
42) *Viz: Bold powerful algorthms jinx crypto key quest.
44) *Jerk encryption quite throughly vexes amazed waifs.
45) *Backdoor jazz hypes extremely quiet NSA info viewing.
46) *Quiz every flawed, grumpy, noxious, abject blatherskite.
47) *Before now, cryptic glyphs vexed Jake's quiet amazed wife.
47) *Fear adjusting public-key numbers to quiz vexed, watched.
49) *Lame vexed xenophobes fear crypto's jazzy, quaint workings.
49) *Vexed xenophobes fear crypto's jazzy, quaint, magical works.
55) *Each solves a major wonderful vexing puzzle, mystery, or book quest.
56) *Mystic glyphs of questionable, exotic, or unknown value just dazzle.
56) *Jack, never fight excitement, wonder, and surprize in your able quest.
57) *Solve Grandview Algorithm by quizzical search for juxtaposed keys.
58) *A checked quisling views both a jinxed and a zero future as a spymaster.
--
Rats! (What Gov. Bush is apt to say the morning after the election)
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Tue, 12 Sep 2000 21:35:38 -0600
In article <8plkse$2bl$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Pray tell, what does C99 do to help people deal with large files easier
> than in the C89 days? Is long long related in any way to fseek and
> friends?
Yes and no -- it's not required to be, but it's relatively
straightforward to use it as an fpos_t that (as an extension) allows
arithmetic on file positions. Yes, with most machines it would also
have been possible to use some large floating-point type within the
range where it could represent all the integer values, but this is
usually pretty clumsy, and makes it easy for a user to accidentally
stray into a range where the type can no longer represent all the
integer values. This is particularly difficult to make at all
portable, since (at least prior to C99) the standard said almost
nothing about floating-point representations. Even now most of the
new floating-point stuff is optional, so it's still hard to guarantee
much.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
Date: Wed, 13 Sep 2000 00:50:27 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
=====BEGIN PGP SIGNED MESSAGE=====
Andy C wrote:
> A friend of mine brought me this algorithm that some software he uses has
> embedded in it.
[snip]
> Ok, now for the question - is this secure enough?
No, the key length is only 32 bits, for example. It's an interesting exercise
to break it without use brute force, though.
First look at the structure of the algorithm, defining auxiliary functions
for anything that looks vaguely complicated. Categorise these functions as
invertible or not, and perhaps note any other interesting properties (e.g.
do they use only linear operators? - although nothing that complicated is
necessary for this example). The specific values of any "magic constants"
probably don't matter either.
Write the algorithm as pseudocode similar to whichever language you're most
familiar with, extended with mathematical notation, and simplifying as much
as possible. I find short variable names better; you're trying to arrive
at something that you can take in at a glance and fit in memory (human
short-term memory is really quite limited).
For example:
// plaintext and ciphertext are viewed as a sequence of 32-bit words
uint32 P[], C[];
for (i = 0; i < P.length; i++) {
// f is an invertible function on 32-bit words
temp = f((P[i] + k) mod 2^32);
C[i] = temp; // ***
k = (k + temp + constant) mod 2^32;
}
// and some junk swapping two array elements, that doesn't matter
// because it is unkeyed.
Determine what the secret state is at any point (in this case only k).
Consider what happens if a plaintext/ciphertext pair is known. E.g. at
point ***:
C[i] = f((P[i] + k) mod 2^32
k = (f^-1(C[i]) - P[i]) mod 2^32
Voila, with a single known plaintext/ciphertext pair we have k, which is
the complete secret state. The algorithm isn't strong enough to be able
to learn anything more about cryptanalysis from it.
> I'm wondering about the "magic numbers" this appears to have in the <<
> and >> and addition areas. Is that the proper place to start looking?
> And if so, what am I looking for?
You should be able to recognise these as a standard idiom for a cyclic
shift (the left and right shift offsets add up to 32). That's why f is
invertible (it is the composition of three invertible functions: two
cyclic shifts and a constant subtraction).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOb7AzjkCAxeYt5gVAQEz/wf9H1TShbDVC6ZgNdG9v8S2JE9ztpE4MQpR
hPU1UUDI4CjJu/y1WpFJi+8LVSk9nWUjiPF1i3qbUDlXuAAXaFx8lgthh9xndtct
EJkTdpGabVwrvKHmfNob7VVcLBqZSyh1IYWJmcj45/dlCPS25LHZ9kSyQNXo5/29
qtUFXhnQP1Z6o3m8L+lqJGlzY6ucPmsNYocjUPJTZN/GaFXfyCpzepzf7/3holfW
qj7FheDHTfXtMGmvBhP2FuRyVx5a6zrBSr/oW5ib9/hy34WpWebESo4x7wmdQR7i
MLZPqV9CCa3tl0B10Nd3JOoOxRyKZHl7GV6ozKRMv5Gkwc342t6y5w==
=oYwX
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 13 Sep 2000 01:16:30 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MAC
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>
> So why not just use the old public key system to sign your message then?
>
> The MAC method implies that the sender and receiver share a common
> secret key. What are the benefits of MAC over standard signature using
> public key encryption?
Computing a MAC is faster. It is quite common to use public key methods
to agree a MAC key, then use the MAC to authenticate packets of data
sent over a connection - this is much more efficient than signing each
packet would be.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOb7HPDkCAxeYt5gVAQGA9Af6ApIdioT0lFchI5b5AaQo8Vr3TUAEsyKg
ZFIhV6asGgEEBN3r/JAiMUh5T5zdjltZdIHG4pZc7cV2LVohSnpquMJDYj2fvnuv
wHBa5yPfIvi1vChUK9Fj9UD/BEXmbn0wgHayPpqr08gI+Q0PfLgH3AeXWnrFpVH6
2mbl0FO6mlewUIAkTHNb9gENM3FEOtxx583p+UMnQab1KFKuyRyyeS3C37uXC5UX
fWaVAZ70OchWt5XeUldIc5WZhlcyX9glIN8zwxS2BY/Hvy11hJDQZlSlcHwNFGwj
8XmTnAFnK3bEoUTKy0bF7++Ym7I4+q16PfO7Ztn6GdClZt59qsvfUA==
=klBy
=====END PGP SIGNATURE=====
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: SV: Intel's 1.13 MHZ chip
Date: Wed, 13 Sep 2000 03:55:42 GMT
> /*T - tera p - pico 1 000 000 000 000*/
>
> Aw, come on, you forgot peta and femto, exa and atto, not to mention
zotta and
> zocto, yotta and yocto. :-P
I saw zotta in the theater last year. Good flick. Very fast action.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: SV: Intel's 1.13 MHZ chip
Date: Wed, 13 Sep 2000 03:56:28 GMT
In article <OjiafWRHAHA.326@cpmsnbbsa09>,
"Abyssmal_Unit_#3" <[EMAIL PROTECTED]> wrote:
> yocto !
>
> how about infinto! or statico!
And don't forget my favorites: mumbo and jumbo!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 13 Sep 2000 03:59:13 GMT
> What's funny is that not even 8086s are as slow as 1.13 MHz. :->
Actually, the CMOS version of the 8086 was clockable with a toggle
switch.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: S.I. unit names, off-topic (was re Intel's 1.13 MHZ chip)
Date: Wed, 13 Sep 2000 03:58:00 GMT
> Not quite; the correct symbol for *1000 is, somewhat inconsistently,
> lowercase k (e.g. kg, km, kHz).
>
> > H - hecto c - centi 100
> > D - deca d - deci 10
> >
> > precede the unit abbreviation, which, in the case of Hertz
(formerly,
> > in English, c.p.s. or cycles per second), is Hz.
>
> To be even more horribly pedantic, the name of the unit is hertz
> (lowercase h), which is indeed abbreviated Hz. Despite common usage,
> this is the correct rule for all S.I. units named after people, e.g.
> newton -> N, siemens -> S, henry -> H, pascal -> Pa, etc.
HK - Henry Kissinger
GB - George Bush
W - Lil' George Bush
AG - Father of the internet
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 13 Sep 2000 03:59:47 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> "S. T. L." wrote:
> >
> > What's funny is that not even 8086s are as slow as 1.13 MHz. :->
>
> It is indeed funny that several people ignore my errata and
> continue go generate lots of noise. Maybe they couldn't
> read.
or "think"?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 13 Sep 2000 04:00:48 GMT
> >> What's funny is that not even 8086s are as slow as 1.13 MHz. :->
>
> >It is indeed funny that several people ignore my errata and
> >continue go generate lots of noise. Maybe they couldn't
> >read.
>
> Myself, I would have been content to just ignore the error. Intel's
> 1.13 whatever chip has been recalled. I didn't even know they had a 1
> GHz chip out just yet. So I found that to be interesting news.
Ya, I was going to keep my mouth shut and not say I didn't know
either...
> The original 8088 was 4.77 MHz, but there were 1 MHz versions of the
> 8080 and 6800, if I'm not mistaken.
And a DC clockable CMOS version too.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 13 Sep 2000 04:03:34 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Mon, 11 Sep 2000 13:18:54 -0400, "Abyssmal_Unit_#3"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >MECL (Motorola Emitter Coupled Logic) architecture has been
available for close to 25 years with capability to perform at 1 to 2 gig
> >rates.
>
> Note, though, that ECL has much higher power consumption than CMOS,
> and supports much lower chip densities. (It's worse than bipolar,
> because it gains its speed by not driving its transistors to
> saturation.)
Yes, but CMOS drains a lot more power with higher clock rates, from
what I remember reading some time back. CMOS is basically shorting the
upper and lower rails during the clock transition and so the faster the
clock the more short circuit you enjoy in a given period of time.
> Also, the 1 GHz speed of a microprocessor is for a machine cycle,
> which involves many elementary logic operations. The figure you quote
> may be the speed of individual NAND gates.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Tue, 12 Sep 2000 20:56:18 -0700
Paul Pires <[EMAIL PROTECTED]> wrote in message
news:n3zv5.82540$[EMAIL PROTECTED]...
>
> Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
> news:8pjugo$l7q$[EMAIL PROTECTED]...
> >
> > Paul Pires <[EMAIL PROTECTED]> wrote in message
> > news:cI%u5.61866$[EMAIL PROTECTED]...
> > >
> > > Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
> > > news:8phpk5$plr$[EMAIL PROTECTED]...
> > > >
> > > > Paul Pires <[EMAIL PROTECTED]> wrote in message
> > > > news:U_Yu5.60123$[EMAIL PROTECTED]...
> > > > > Why would anyone brute force the key. It seems to me that if
> > > > > you can be made to encrypt some known material at the
> > > > > beginning of a file, I get your key using only a pencil and
> > > > > paper.
> > > > >
> > > > > first tempKey = theKey;
> > > > >
> > > > > > temp1 = data[counter] + tempKey;
> > > > > > temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > > > > > temp1 = ((temp1 << 23) | (temp1 >> 9));
> > > > > > tempData[counter] = temp1;
> > > > > > tempKey = tempKey + temp1 - 26087;
> > > > >
> > > > > Let's refrase the first cycle:
> > > > >
> > > > > temp1 = plaintext + the honest to god key;
> > > > > temp2 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > > > > temp3 = ((temp1 << 23) | (temp1 >> 9));
> > > > Actually, this should be:
> > > > temp3 = ((temp2 << 23) | (temp2 >> 9));
> > > >
> > > > > ciphertext= temp3;
> > > > > tempKey = tempKey + temp1 - 26087;
> > > > Actually, this should be:
> > > > tempKey = tempKey + temp3 - 26087;
> > > > Neither of these affect your attack materially...
> > >
> > > Sorry for the typo's. I finally found an easy one to respond to
> > > and was rushing like mad to post it before the real guns saw it :-)
> >
> > No problem -- I know the feeling. "I gotta get this break out before
Wagner
> > sees the post, and stomps the system flat..."
> >
> > > > Actually, this attack can be strengthened somewhat, in that it can
be
> > > > applied to any block (and, it relies on a known plaintext block,
rather
> > than
> > > > a chosen one as you appeared to have implied). Suppose you
know/guess
> > the
> > > > value of plaintext block 10. Then, you use the above attack to
derive
> > the
> > > > value of tempKey at the start of the encryption of block 10. Then,
> > looking
> > > > at the last two steps of the iteration for block 9:
> > > >
> > [snip]
> > >
> > > Yep, that works too.
> >
> > Actually, thinking about the system some more (yes, I don't have a
life...
> > why do you ask?), the system is essentially:
> >
> > C = F( P+K )
> > K += C + Const
> >
> > where:
> > P is the plaintext block
> > C is the ciphertext block
> > K is hidden state, initialized to be the key
> > Const is -26087
> > F is an unkeyed invertible 32 bit->32 bit function
> > Finv is the inverse of F
> > All addition/subtraction is done mod 2**32
> >
> > then,
> >
> > Finv(C) - P = K
> >
> > Then, if we have two adjacent ciphertext blocks C1, C2, then
> >
> > Finv(C1) - P1 = K1
> > Finv(C2) - P2 = K2
> > K2 = K1 + C1 + Const
>
> Be gentle, If I go FUBAR here, please forgive.
>
> Doesn't this also mean that K2-K1 = C1 + Const ?
Well, yes
>
> Wouldn't this mean that the diference between adjacent round
> keys is defined entirely by the first ciphertext? So if C1 is
> (2^32) - Const , Then C1 + Const = 0, and K2 = K1 ?
>
> Wierd property. I wonder if you could craft a chosen ciphertext
> hack on it? Some way of fooling the guy into handling two
> adjacent blocks with the same working key.
>
> What does that get me? I think I just lost myself.
Actually, you're not really interested in the keys, you're interested in the
plaintext -- you care about the keys only because it'd give you the
plaintext. And, once you do have the plaintext, you have already shown how
to go back and get the keys if you care to.
And, we have:
> > P2 - P1 = Finv(C2) - Finv(C1) - C1 - Const
> >
> > Everything on the right side is known to the attacker, and so he can
deduce
> > the arithmetic differences between any two blocks. Depending on the
> > characteristics of the plaintext (eg. if there is a checksum of all the
> > blocks at the end of the plaintext), this may make recovering it real
> > easy...
or, in other words, for a given set of ciphertext blocks C[], there exists a
key-independent transformation that gives a set of blocks C'[] such that:
P[i] = C'[i] + K mod 2**32
for some unknown K (which is not the attackers key), which is identical for
all the blocks (and P[] are the plaintext blocks).
How can this help? Well, we can make this transformation, and pretend that
the above "add" cipher [1] was being used. And, this cipher has obvious
weaknesses. For example:
- If you have the lower 16 bits of one block, and the upper 16 bits of
another, you can rederive K, which gives you all the plaintext. For that
matter, as long as for each bit N, 0<=N<32, you know that value of that bit
for *some* plaintext block, you can rederive K.
- If the packet has a checksum (either additive or xor based), then this
formula allows you to figure out K efficiently.
[1] I dup it the "add" cipher because it is analogous to the "xor" cipher
beloved by klewless newbie cryptographers everywhere...
--
poncho
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: OutLook Express & SMIME
Date: Wed, 13 Sep 2000 04:10:00 GMT
> I am experimenting with SMIME and have got myself a
> free certificate from Thwaite. This all works fine.
In trying to find a work around to the Microsoft crypto provider
signature, I reasoned that a DLL could insert between the application
and the crypto DLL, much the same way that bounds checker and other spy
utilities insert themselves to monitor parameter and API activity. This
insert technology is found in papers published by Microsoft, as is the
technology to front end (replace) any API call into a DLL by modifying
the IAT.
I reasoned that my injected DLL could intercept the call to the encrypt
or decrypt APIs and perform the overwhelmingly strong cipher operations
in place of the weak (and very useless) crypto DLL installed and
recognized by the operating system. Indeed this worked with no
problems. I was able further to compromise Microsoft Outlook Express,
for example, by intercepting the plain text that was to be encrypted
and broadcast it over the internet, then encrypt it as expected to
prevent surface detection. This represents a covert virus attack
scenario.
Of course, once I figured out that this could be done, I decided that
it would be pointless to ever deploy a crypto DLL product- ever!
I recommend you throw away your certificate and use some real
encryption on an isolated system, use sneakernet to transfer your
encrypted data (say on a floppy disk) and attach it to your e-mail.
Other wise, why bother?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
