Cryptography-Digest Digest #600, Volume #10 Sat, 20 Nov 99 21:13:03 EST
Contents:
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: Nova program on cryptanalysis -- also cipher contest (Troed)
Re: Distribution of intelligence in the crypto field ("Chip Anderson")
Secret Code Breaker, Suby Crackers (JPeschel)
Re: AES cyphers leak information like sieves (John Savard)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: Cryptological discovery, rediscovery, or fantasy? (Steven James Forsberg)
Re: AES cyphers leak information like sieves (Toby Kelsey)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: technical writing skills required! (Tom St Denis)
Re: bits of diffiehellman private key (Tom St Denis)
Re: Do flight data recorders use encryption? (Anti-Spam)
Re: Cryptological discovery, rediscovery, or fantasy? (Johnny Bravo)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 21:49:56 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(wtshaw) wrote:
>In article <816fun$p2s$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>>.... Guessing the entries to a random S-table is very hard.
>> But guess a function that has lower complexity is much easier as the
>> number of permutations decreases.
>>
>This goes to the heart of my wanting to separate main algorithms from
>keys, although a suggested key generation procedure might be recommended.
>As I do, you do too, have a large enough runtime key that can be produced
>by a number of methods. It seems to me that this is a good way to divide
>a cryptosystem into better handled subassemblies.
>
>Surely an immense S-table could just as well be generated from a single
>pRNG seed to a handpicked series of values equal to the size of the table;
>true keysize would be from very small to very large, but the algorithm
>would work the same. Don't forget many intermediate generation approaches
>that are doable.
Yes I think we agree here.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Nova program on cryptanalysis -- also cipher contest
Reply-To: [EMAIL PROTECTED]
Date: Sat, 20 Nov 1999 21:30:17 GMT
William Rowden <[EMAIL PROTECTED]> wrote:
>only narrowed the locations to a score or so each. Attempting to
>reconstruct the Playfair square for a few of these locations by hand
>motivated the writing of a computer script to search the permutations.
>
>The computer's first pass with the script produced four partial Playfair
>squares for testing--a number of squares this human was willing to try.
I'm also writing a "solve Playfair" program at the moment ... not the
same contest. So far I've managed to narrow down lots of rules on what
a Playfair square can and cannot, but I haven't really been able to
get it all automated.
What I have in the program so far is extraction of the bigrams, their
count, and then it does some basic plaintexts exchanging most common
cipher bigram for most common bigram in selected language etc.
If you have any brief examples of how to get "same row or char above"
rules into C/C++ I'd be happy to have a look ;)
___/
_/
------------------------------
From: "Chip Anderson" <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: Sat, 20 Nov 1999 17:06:07 -0600
<amadeus @0SPAM.netcomuk.co.uk (Jim Dunnett)> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 20 Nov 1999 09:34:24 GMT, [EMAIL PROTECTED]
(Troed)
> wrote:
>
> >M Okra <[EMAIL PROTECTED]> wrote:
> >
> >>I think the best way to solve once and for all the questions of whether
> >>and how far ahead NSA is of the commercial and hobbyist world of
> >>crypto is to poll this newsgroup. Who could be dissatisfied with that?
> >
> >The best way is to plot a MURDER of the PRESIDENT (you know, the one
> >in the WHITEHOUSE) - and encrypt those plans with 2048 bit RSA. If you
> >get arrested - hey, that means they can decrypt it ;)
> >
> >Echelon will forward this message to them now ...
>
> On the other hand, why are they so trying so hard to suppress strong
> crypto, key-escrow etc. if they can hack PGP, for example?
>
Maybe because common use of encryption (easy for everyone) for all
communication would cause a problem with 'routine' intelligence gathering.
Chip
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Secret Code Breaker, Suby Crackers
Date: 20 Nov 1999 23:26:05 GMT
To my site I've recently added a link
to Bob Reynard's new site for the <i>
"Secret code Breaker Online</i>.
Also, you'll find two new crackers for
Smart Crypt-It and Icon Lock-It
by Suby. These include the cracking
source code in ASM. Suby also has
promised to send me the respective
cracking essays in a week or so.
My Russian friend Pavel Semjanov
is also hosting Suby's crackers.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 23:22:16 GMT
On Fri, 19 Nov 1999 23:05:17 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>...and perhaps another idea - the notion that compression for use with
>encryption should have a property (which he calls one-on-one) in order
>to circumvent particular types of attack on the surrounding encryption.
And I should not have forgotten that one, since I thought enough of it
to present my own variation of it on my web site, in the section
entitled "Tying Up Loose Ends".
I suspect that it's an idea of limited usefulness except in
specialized applications (think of EKE, where encrypting a modulus is
useless because brute force search on the small password is still
possible); but just saving bandwidth is worthwhile. But I don't follow
through with "true" one-to-one encryption: I still advocate random
padding as the way to fill the message out to a whole number of bytes:
I show how one can compress in a (nearly) one-to-one fashion to
produce an arbitrary-length string of bits only.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 20 Nov 1999 23:54:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Fri, 19 Nov 1999 03:37:51 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >In article <8124qm$2itg$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >> Obviously I know more about it that you no wonder you don't
> >> know shit about crypto.
> >
> >First off, please translate the above from idiot to english.
> >
> You know, besides being really funny, in thinking about it, this makes
> a lot more of what scott says make sense. I didn't read it in the
> right dialect!
>
> Thanks for the chuckle...
You know what's even more funnier? Is although I have no clue about
finite [ I am taking a course next semester ] and that all my math
looked smart [but was wrong] I still manged to make someone have fun
reading sci.crypt.
I am seriously sorry for posting the info on rotors. If it was right
thats good, if I was wrong, well I am trying to keep people on their
toes!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steven James Forsberg)
Crossposted-To: sci.math,sci.misc,alt.privacy
Subject: Re: Cryptological discovery, rediscovery, or fantasy?
Date: 21 Nov 1999 00:04:52 GMT
: What good is an unbreakable cipher system if your
: enemy is capable of capturing you and gaining
: the key from you by force? Most humans will surrender
: a password if placed under duress. In fact, this is
: one of the most frequent ways in which encryption is
: compromised.
This is why, in most modern systems, no human ever
sees the key (at least modern government systems). The key
is loaded from superenciphered memory in an electronic device
which takes two or more people entering "key segments" in
order for it to work. And even then, there is yet *another*
level of decryption on the machine to be loaded.
In other words, you and some other person each hold
half a key. You enter your halves into the key loader. It then
transmits a key sequence to the machine, which itself uses a
built in key to further descramble and come up with the "real"
key. In order to get the ultimate key you must A) corrupt more
than one person loading the key B)get a copy of the key as it
is downloaded (no human ever sees it). C)get a copy of the
machines internal key.
I would argue that the field has seen a reversal in the
"best" method for acquiring enemy secrets. It used to be that
stealing the key was the best way to get mass data (since a spy
would have trouble carrying so much material). Nowadays, however,
with mag media etc. (disks,CD, etc.) and improved key security, it
may well be easier to have a 'spy' carry out mass material on a
mag media than it would be for them to steal a key. Still, near
realtime decryption is nice.....
: A technique for the encryption of data which would
: involve a combination of encryption and steganography
: (the science of concealing the presence of data.)
Such methods have been worked on, no doubt, but I'm not
award offhand of any in use, and I've asked sci.crypt before. One problem
would be generating enough realistic "fake" message data to fool an
opponent. Another way is to use one key but to include lists in theI
original data stream, without indicating which option is correct. For
example: That attack starts at A)0600 B)0900 C)1300 D)No attack.
The method you propose sounds a lot like channelized bulk
encryption, as you might find on a topline bulk carrier. Basically, any
number of enciphered data streams is fed into a single unifying cipher
stream to hide information about the original threads (often using 'steady
stream' as well).
regards,
=======================================
[EMAIL PROTECTED] wizard 87-01
------------------------------
From: Toby Kelsey <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Sun, 21 Nov 1999 00:00:54 +0000
>David Wagner wrote:
>> (The idea of compressing before encrypting isn't new. ...
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn <[EMAIL PROTECTED]>
writes
>What the one-on-one scheme (as I
>just described it) does is to render a brute-force attack
>*infeasible* even if one *has* the necessary hardware to
>try all possible keys in a reasonable amount of time.
>So far as I know, that is an original contribution to the
>state of the cryptologic art.
Check <[EMAIL PROTECTED]> posted on 02/02/1999 for
the original exposition. Ironically I was correcting dscott at the time.
Toby
--
Toby Kelsey
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sun, 21 Nov 1999 00:00:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Johnny Bravo <[EMAIL PROTECTED]> wrote:
> : On Thu, 18 Nov 1999 18:33:02 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
> :>David demonstrates this by chopping the head and tail from the
cyphertext
> :>message, and decrypting it anyway (using the key). This would be
> :>impossible if the plaintext information were diffused through the
whole
> :>message.
>
> : You might as well assume your attacker just has the middle third
of
> : the plaintext sitting right in front of him as well. Of what
> : practical use is basing an attack on your attacker having the key?
>
> You don't seem to grasp David's point. Perhaps you've been listening
to
> Tom? David is *not* proposing this as an attack. It's a
demonstration
> that all the information needed to decrypt a file section is present
in
> that section (give or take a block at the end).
Maybe Tom was suggesting that realistic single block attacks on modern
ciphers, aren't.
> : What are the odds that your attacker will have your key, your IV
> : (which is usually in the front of the message) and ONLY the middle
1/3
> : of the ciphertext?
>
> The IV is only useful for decrypting the first block. Other blocks
may be
> decrypted without it. I stress again, we are not talking about an
> attacker encountering these circumstances.
Uh? No. You need to xor the previous ciphertext against the decrypted
block to get the plaintext back.
See my comment above.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: technical writing skills required!
Date: Sun, 21 Nov 1999 00:08:18 GMT
> I think that's a good idea. Posting short sections in a single thread
> would make comments easy to find, and edits easy to suggest using the
> Usenet quote-response convention.
Would it be more usefull just to divide the paper into small text
files, then just post urls? I don't want to flood the group. Assuming
I can muster enough time todo this [which I want to]. I could then
edit it into one document when it nears completion...
> Dealing with criticism can be difficult. The noise (name-calling,
> arrogance, swearing, etc.) and flames of some when challenged attest
to
> this. A few posters in sci.crypt only recently received a reprieve
from
> my killfile. (Though I doubt they know or care.)
I can deal with comments and criticism as long as I can expect help as
well. For example saying 'your grammar sucks' is one thing,
finding/fixing the errors is another.
>From what I have seen the more mature responsible posters here are
normally very helpful.
> You already know my *real* email address.
Actually I have deleted all my older email. You can contact me at
[EMAIL PROTECTED] if you want to help out.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: bits of diffiehellman private key
Date: Sun, 21 Nov 1999 00:13:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> You wouldn't use sieving (i.e. index calculus-based algorithms) to
attack
> this; you'd use a "baby-step giant-step" algorithm modified to work
on a
> restricted exponent space. The following algorithm, which finds
> x = log_g(y) given g and y, is adapted from [HAC]:
Thanks for the info I will look it up in more detail.
My question is however does it work if the bits known [or biased] are
not clumped together? I am taking this to the extent of peekboo with
the timer rng. My question is basically if say some parts of the bits
are biased but not fixed [thus not always known, thus the known bits
are not always clumped] does it work?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anti-Spam <[EMAIL PROTECTED]>
Subject: Re: Do flight data recorders use encryption?
Date: Sat, 20 Nov 1999 16:17:05 -0800
Jim Dunnett wrote:
>
>
> And undoubtedly the Egyptian government and airline is present at
> all stages of the investigation.
>
> Covering up for Boeing would hardly be doing Boeing or its
> customers any favours!
Agreed. The audit trail covering the manufacture, certification and
installation of any piece of avionics equipment on a FAR Part 25
aircraft in FAR Part 121 / part 135 operation distributes across so many
players - and that's the key to preventing "fake" data. There are just
TOO many documents and details over the operational history of the
device to "fake" it. There are too many interested parties checking
over all of that documented history ( the airline, cert agencies,
governments, lawyers, manufacturers of the airframe, manufacturers of
the box, suppliers for box parts ) to get past.
Here's a good example of a situation that does not require encryption -
too many players are involved to make it possible to successfully "fake"
information without ALL players colluding or actively participating in
the "lie." (Sounds like a protocol?)
Consider what it takes for a single player in this scenario to
successfully "fake" the data WITHOUT cooperation from all other players:
1) One player replaces the original data recorder with an IDENTICAL
recorder full of "fake" data at the crash site before anyone else gets
to it.
The idea of one player orchestrating a "replacement" of a box, and
getting it 100% correct in terms of internal materials, serial numbers
on internal components, serial numbers on the box itself, constructing
internal data to match civilian ATC and military recordings of all
aspects of flight (radar, voice) and then planting it at a crash site
immediately after a crash requires significant suspension of common
sense.
2) One player replaces the original data recorder with a NEW recorder
full of "fake" data at the crash site before anyone else gets to it, and
THEN replaces all of the document audit trail for the original recorder
with NEW documents.
The idea of one player faking the entire document audit trail for a box
including recorded serial numbers and manufacturing drawings at the
avionics supplier and its suppliers, installation drawings and
maintenance records with the installer or the OEM for the airframe, and
the maintenance records for the airline/carrier using that box, AND
orchestrating a "replacement" with a box full of internal data matching
civilian ATC and military recordings of all aspects of flight (radar,
voice) and then planting it at a crash site immediately after a crash
requires EXTRODINARY significant suspension of common sense.
- BUT -
It is possible to withhold findings & data (i.e. "fake" the results) if
ALL player AGREE. And encryption or digital authentication cannot help
us in this situation.
There is only one example (that I know of) of such a documented
cover-up. NOVA on PBS in the US ran an episode covering the crash of
the TU-144 "Concordski" at the Paris Airshow in 1972 (?). The show
revealed the French and Soviet governments JOINTLY withheld information
about the tragic crash of the supersonic airliner during a demonstration
flight over Paris. The French authorized a high-speed reconnissance
aircraft to "buzz" the TU-144, just above the local cloud ceiling, to
get close-up pictures of the craft while in flight. The pilot of the
TU-144 did not know about this. The French aircraft spooked the Soviet
pilot when the TU-144 climbed up above the ceiling. He rapidly
manouvered to avoid the French aircraft but overstressed his airplane.
The TU-144 disintegrated and killed the Soviet crew and several French
civilians below.
A JOINT French-Russian investigation team reached nebulous public
conclusions about the nature of the TU-144's unfortunate "accident." The
TU-144's design and pilot error took the blame. No one revealed the
true reason for the crash until a few years ago - and then only due to
Soviet internal documents made available to the West. AFAIK, France
still does not offically acknoweldge its actions as the cause of the
crash.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: sci.math,sci.misc,alt.privacy
Subject: Re: Cryptological discovery, rediscovery, or fantasy?
Date: Sat, 20 Nov 1999 19:18:39 GMT
On Sat, 20 Nov 1999 15:18:37 -0500, DSM
<[EMAIL PROTECTED]> wrote:
>What good is an unbreakable cipher system if your
>enemy is capable of capturing you and gaining
>the key from you by force?
Crypto makes no promises about human factors. For that matter,
there is no crypto you can use that would prevent the authorities from
just capturing you and torturing the plain text info out of you.
>Now, consider the following:
>
>A technique for the encryption of data which would
>involve a combination of encryption and steganography
>(the science of concealing the presence of data.)
>
>A block of data could be made to hold two messages.
>One password fed into the algorithm would reveal the
>valuable message, while another would unravel text
>which is not as compromising but equally likely to
>get you out of the torture chamber (or court room, if
>you are within the borders of an
>"industrial democracy.")
So what, they find out such a method exists and just tortures you
until they get both messages. If you only have one message, they just
torture you to death and when you are dead, they can be sure they got
everything there is to get from you.
Best Wishes,
Johnny Bravo
------------------------------
** 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
******************************
