Cryptography-Digest Digest #581, Volume #10      Wed, 17 Nov 99 14:13:01 EST

Contents:
  Re: Any good cryptographers out there? (Ragnar Lonn)
  Re: AES cyphers leak information like sieves (John Savard)
  Re: weak ciphers and their usage (SCOTT19U.ZIP_GUY)
  Re: Codebook examples on Web? (John Savard)
  Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
  Re: Codebook examples on Web? (John Savard)
  Re: AES cyphers leak information like sieves (Volker Hetzer)
  Re: AES cyphers leak information like sieves (Tim Tyler)
  Re: Group English 1-1 all file compressor (William Rowden)
  ATTN Scott Nelson (CoyoteRed)
  Re: What sort of noise should encrypted stuff look like? (Tim Tyler)
  Re: Re: PGP Cracked ? (CoyoteRed)
  Re: International crypto restrictions (Paul Koning)
  Re: Ultimate Crypto Protection? (Paul Koning)
  Re: AES cyphers leak information like sieves (Paul Koning)
  Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
  Re: "Compressible Encryption" - Is it an oxymoron? ("John E. Kuslich")

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

From: [EMAIL PROTECTED] (Ragnar Lonn)
Subject: Re: Any good cryptographers out there?
Date: Wed, 17 Nov 1999 15:39:19 GMT

In article <[EMAIL PROTECTED]>, Volker Hetzer 
<[EMAIL PROTECTED]> wrote:
>> So, what does this have to do with cryptography?  Well, the network protocol
>> this game is using is encrypted!
>Well, couldn't you just ask the guys who wrote it?
>

I did and they said they couldn't give out any information about the network 
protocol for security reasons. Security through obscurity is never a good idea
but they do have one point here and that is that in first-person shooter games
like e.g. Quake it is possible to write cheater 'bots' that aim for you and 
dodge bullets etc with superhuman speed if you have knowledge of the network
protocol. The game server sends out positional info to the clients, telling 
the clients the position, heading, and velocity of objects in the game (like 
e.g. other players in the game). Normally, this info is used by your game 
client to display the things you see on your screen. Then you have to
decide whether that guy coming at you is a friend or foe and press the trigger
if he's the latter. You also have to determine, in many cases, where the foe 
will be in a second which is perhaps the time your weapon takes to fire or
for your grenade to arrive at the target. Basically, you have to aim :-)

If you know how the network protocol works you can write a program that sits
in between your game client and the server and calculates the probable 
locations of all your visible enemies the next second and shoots a grenade
for you at all those exact spots. This can be very effective in shoot'em'up 
games like e.g. Quake. Tribes is also a game where this would be very 
effective, which is why the game developers don't want details of the network 
protocol to become public. It kind of sucks but neither they nor I can think 
of any good way to protect against this type of cheating. At least not without 
wasting copious amounts of bandwidth (e.g. sending a raw video stream instead 
of positional info to the clients. Not completely safe either but harder to 
analyze). 

Because of this, I will not pass on any info about the protocol that I may 
find out. It sucks and it isn't really a viable way for the future but today 
it's probably the only way to prevent people from cheating.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 15:47:04 GMT

"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>"Douglas A. Gwyn" wrote:
>> I would be interested in *one* example of a well-respected block
>> cipher that *does* provide error recovery.

>From later postings, it appears that they were talking about
>a common side-effect of many block chaining modes.  But it was
>ECB style that was being complained about, and for an individual
>block, the cipher provides no error recover.

It also provides no error _propagation_, and since that also limits
the damage done by an error, that is what he meant: David A. Scott has
his own variant of PCBC mode that propagates errors backwards as well
as forwards, which Mr. Tyler is commending to us.

John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: weak ciphers and their usage
Date: Wed, 17 Nov 1999 16:40:40 GMT

In article <80uf90$bb9$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]> 
wrote:
>You obviously haven't followed this thread MR Scott.
>Tom was talking about an attack on 2 almost identical files.
>David Wagner quite rightly pointed out that fresh IV solves this known
>problem.
>

    Yes I have followed the thread. But it seems like people are talking
about two different things. Yes ECB is the worse mod. The point is that
other 3 letter Mods can be very bad. I have been talking about the general
weaknesses in all 3 letter chaining mods. The IV change can make a file
appear to be different. In fact it can be such that different mappings are 
used for each input output pairs of the block cipher. But it does no change
the fact that the information of the plaintext is not spread through out the 
whole file.  And this can clearly be seen by just takeing a portion of the
encrypted file and using the wromg IV and a different starting block
and start the decryption with the correct key and after a start up the
rest of fragment gets decrypted to the correct plain text. So the info
is not really spread through the file it is an illusion that most people 
don't understand and it is the reason that the real world plaintext attacks
can work if the enemy only knows a fragment of the plaintext file some where
in the encrypted message. This kind of plain text attack could be avoided
if people used "wrapped PCBC" or its equivalent.  The advantage of
wrapped PCBC is this. In the weak 3 letter methods if one has a portion
of the plain text file and the matching encrypted file one has many plaintext
cipher text pairs to examine the block cipher. With a mod like "wrapped PCBC"
even if the attacker has some plaintext ciphertext files. He can not easily 
determine any of the plaintext cipher text blocks that where pairs to the
underlying block cipher. This information that you get for free with the
3 letter chaining modes is not free to the enemy when you use 
"wrapped PCBC" or its equivalent.



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] (John Savard)
Subject: Re: Codebook examples on Web?
Date: Wed, 17 Nov 1999 15:51:44 GMT

[EMAIL PROTECTED] wrote, in part:

>Any thoughts on the 'codebooks revisited' item?

It is a good idea, but it should be renamed. Never use the words "one
time" for any system that doesn't use genuinely random numbers, not
PRNG output, for the different key used with each message, if you want
to avoid a storm of controversy coming down around your ears!

John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.pgp
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 16:45:09 GMT

In article <80u9hi$pin$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED] (John Savard) wrote:
>> Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
>>
>> >That block cyphers allow recovery from errors in single blocks is a
>> >*pathetic* excuse for leaking this type of information to analysts
>on such
>> >a dramatic scale.
>>
>> ECB mode is *not* recommended for normal encryption use, and only ECB
>> mode has the specific problem you outline. (Note, of course, that if
>> the map had any background coloring on the island that varied, the
>> problem wouldn't arise.)
>>
>> The commonest mode, used in PGP, is CBC, Cipher Block Chaining.
>
>I thought PGP used IDEA [originally] in CFB mode?
>

  This is a very interesting point. My old PGP documents state the samethng
however Mr Savard has claimed after repeated Emails and comments in this
forum that it used CBC. I have yet to see where he gets the info other that to
claim that his documents say CBC and that I am wrong I wish a PGP code
historian would clear that up. Since I have no idea what PGP use in its 
current form.



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] (John Savard)
Subject: Re: Codebook examples on Web?
Date: Wed, 17 Nov 1999 15:58:03 GMT

[EMAIL PROTECTED] wrote, in part:

>It cost UKP 7.50 - $11 or so!

You were very fortunate. $15 or so Canadian. I've managed to pick up
some old cable codes - but only on two occasions when I was travelling
to Vancouver.

>It was one of a tranche of crypto documents. One, a cryptologic dictionary 
>was marked as US Army/Navy 'top secret cream' (1946). The NSA happily 
>declassified it and its on sale at Aegean Park Press.

What I'm hoping for is that you can put up another page or two of the
decoding section; unlike an American codebook, as I earlier noted, you
may have to worry about Crown Copyright. (Before it heads to
Bletchley, you may want to scan the whole thing for your own use.)

John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 17:01:36 +0100

SCOTT19U.ZIP_GUY wrote:
>     True but the purpose of some encryption is to make the data as hard as
> possible for the attacker to recover. So you can add security by hiding the
> information through out the whole file.
How much security do you gain over a bidirectional CBC with a cipher of
a blocksize of 128 bit?
How much over a normal CBC with a cipher of a blocksize of 128 bit?

The fact that in case of modifications not everything decrypts to garbage
is no problem at all as long as a hash is included in the plaintext.

> Standard 3 letter chaining methods
> give a false since of security by giving the illusion of hiding data through
> out the whole file.
They don't give a false sense of security and no illusion either. They just exist
and have properties that are easy to see for everyone.

>   As my procedure shows. When you edit a file that uses block encyption
> with standard 3 letter chaining even if you do several passes of CBC when
> you decrypt the modifed file only a small set of blocks come bach with errors.
What's the point?
The modes are there to hide plaintext patterns and to prevent dictionary
attacks. They do exactly that.

Greetings!
Volker
-- 
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 16:12:58 GMT

SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: Volker Hetzer <[EMAIL PROTECTED]> wrote:

:>If you want to disguise patterns forward and backward, use CBC twice (in
:>both directions).

:     Actuall when I first got interest in Ciphers many years ago. I did try 
: double CBC and using CBC as two direction passes. But what I found
: out was that when one does either of the 2 methods and you hex edit
: the encrypted file only a few blocks of plain text are messed up. So
: that the information is not really spread throught the file.

First, a disclaimer: what I know about block chaining will probably fit
on a postage stamp.  However, what I /do/ know seems relevant here.

It is true that editing a bit in a file encrypted using this method
will change three blocks.  Two blocks will be changed completely,
and one partially.

However, this does not mean that information relating to the encrypted
text is not spread throughot the file.

If you change a single bit in the encrypted text, the changes should
propagate unboundedly in both directions.

AFAICS, the correct conclusion from the observation that editing
a few bits of the encrypted file results in limited corruption
of the plaintext is that *sometimes* small changes to the plaintext
will fail to propagate.

*Normally*, this failure of the information to propagate will not happen.
If you flip a single bit in the plaintext, for example, it will not
happen - the result of the change will be seen throughout the cyphertext.

However, if you make changes in three adjacent plaintext blocks - and
these changes have a very precise and specific relationship to one another
- then the rest of the cyphertext will be unmodified.

It seems to me that the chances of any modification in the plaintext
causing this failure of the change to propagate throughout the
cyphertext are pretty minimal.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

When we try to make machines learn, it's us who learn, not the machines.

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

From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: Group English 1-1 all file compressor
Date: Wed, 17 Nov 1999 16:25:26 GMT

I don't entirely understand your and Tim's posts--perhaps I missed
part of the thread--, but I think I understand your question.  My
answers are below.  HTH

In article <80hdro$1j76$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>  If some one gives me the most frequently occurring  3 letter groups
> just the top 5.

>From Hitt's _Manual for the Solution of Military Ciphers_, the five
most frequent trigrams (and count per 10 000 letters of military
orders and reports) are these:

     THE (89), AND (54), THA (47), ENT (39), and ION (36).

>From the Army _Field Manual 34-40-2_, the five most frequent trigrams
(and count per 50 000 letters of government telegrams) are these:

     ENT (569), ION (260), AND (228), ING (226), and IVE (225).

> and the most frequesnt occurring 2 letter groups just the top 5

Hitt lists these bigrams:

     TH (50), ER (40), ON (39), AN (38), and RE (36).

The _Field Manual_ lists these bigrams from its five-times-larger
sample:

     EN (111), RE (98), ER (87), NT (82), and TH (78).

The Brown University Corpus (4 743 925 letters from newspapers,
magazines, books, etc.) has these frequencies (per 10 000 digrams):

     TH (361), HE (330), IN (240), ER (204), AN (196), RE (180),
     ON (165), AT (143), EN (140), ND (131), ED (126), ES (124),
     OR (124), TE (116), TI (116), IS (111), IT (111), ST (111),
     TO (110), AR (107), NG (103), HA (101), and NT (101).

(You get extra digrams because I had to scan the table anyway.)  Note
that the Brown frequencies I've given are for digrams not crossing
word boundaries.  (In the phrase "THE MAN", there are four of this type
of digram--TH, HE, MA, and AN--, since EM is excluded.)  I think that's
what you want, but I have the table without regard to word boundaries
also.

> along with the top 5 words

The top words from the Brown Corpus are as follows:

    THE, OF, AND, TO, A, IN, THAT, IS, WAS, HE, and FOR.

(I listed more because replacing "A" with another character won't
result in compression, and the two-letter words won't compress much.)

> the least used characters for the substitution.

For *letters*, Hitt says these are little used:

     K (74), J (51), X (27), Z (17), and Q (8).

The Brown list is identical except for frequency:

     K (66), X (20), J (16), Q (11), and Z (10).

For a personalized Huffman encoding project, I did a case-insensitive
910 337-*character* survey of a friend's Web site (excluding HTML tags).
I found more than 50 different characters.  For 5 each of trigrams,
digrams, and words, you'll need at least 15 low-frequency symbols.
I'll throw in a few more in case you don't want to use numerals:

     '!' (467), '2' (466), '?' (440), '5' (310),
     '8' (299), '(' (280), '3' (254), ')' (252), '/' (120),
     '$' (62), ';' (39), '@' (29), '%' (21), '_' (13),
     '#' (11), '+' (6), '=' (4), '~' (1), and '&' (0).

YMMV:  the source statistics may be inappropriate for general use.

>  I realize the goal is for just words with no carridge returns
[snip]
> Example stage 1 of the 1-1 compress change the dictionary is
> made up of   "the" and "z'"
>
> stage 2  there is a dictionary of "th" and "q"
--
    -William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB  DA28 379D 47DB 599E 0B1A


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

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

From: [EMAIL PROTECTED] (CoyoteRed)
Subject: ATTN Scott Nelson
Date: Wed, 17 Nov 1999 15:13:23 GMT
Reply-To: this news group unless otherwise instructed!

Thanks for your response to the "Another random number generator."  My
news server dropped it and I found it on accident as I was doing a
deja search on some of my posts.

Thanks for the input, but you mentioned that with skipping that the
attacker may be able to resync his samples.  I take it that you mean
/after/ digitizing the signal?  I'm thinking a major problem that he
would have to over come is getting this string of samples as this only
resides in the machine that is doing the generation and then is gone.
Plus, trying to sync his samples to mine if he was listening to my
analog signal would be difficult.  

He would have to have a recording of my analog signal and use some
kind of test to get the same samples as me as he "phase-shifts" and
adjusts the gain of the recording in relation to the sampling
interval.  Then the recording would have to be perfectly the same as
the signal on my machine, no induced noise. With the slightest
deviation in a signal (gain, waveform, etc.) would throw off the
samples, fine tuning would be extremely difficult. (Obviously this
points out that if you use the 'blank cassette scheme' one would then
have to record over or bulk erase this tape to destroy the 'blank'
signal.)

Plus in order to do these tests he would have to have something to
test against.  But let's pretend that he did have the first 100 bit
portion of our number and was trying to get the rest.

So, he has a recording and is time-shifting and adjusting the gain of
the A-D convertor.  It seems that if we are /not/ skipping, then he
could get close and see a large percentage of bit matches, he would
then be able to fine tune his adjustments to get the exact match.
Plus a few bits of noise would not matter that much as he would only
have to try all of the other possiblities.

But with skipping, the bit stream would be so different for each time
and gain differential that he would have to have an exact match before
he even realized that he was close.  Then as soon as he came across a
noise hit he would have to start testing for the next true sample, but
this will only work until he runs out of the stream that he has to
test against.  Plus, the earlier in the stream that he gets a noise
hit the more it would effect his tests.  So, if he has 100 bits and is
running through his time and gain differentials and is testing for say
55% plus matches then a single noise hit early in the stream would not
alert a proper time/gain differential hit.

I don't yet understand MD5 or SHA1 to know how much this will add to
our randomness so my thinking is relying on more mundane means, but
doesn't mean that I don't think MD5 or SHA1 wouldn't be beneficial
though.  So, I'm trying to get randomness and security on a basic
level /before/ we more thoroughly massage the numbers.

But that's what I think anyway.

That's all I can remember about your post as I don't have a web
browser here, so if I've missed anything...

-- 
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com


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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What sort of noise should encrypted stuff look like?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 16:25:01 GMT

Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: wtshaw wrote:

:> Given a *good* spectrum in ciphertext, you can skew it to make a
:> misleading one of your own picking.

: It would cost you bandwidth.  Why bother?

It need not cost you bandwidth.

If you make sure the messages you send most frequently map to cyphertexts
that appear to be some simple, easily-cracked cypher (which decrypts them
as plausible looking, but deliberately misleading messages, you may be
able to confuse the opponent.

I see no reason why this should absorb any bandwidth.  It might bulk up
your cypher-machine, though ;-)
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

Something wonderful has happened.

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

From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: PGP Cracked ?
Date: Wed, 17 Nov 1999 16:19:39 GMT
Reply-To: this news group unless otherwise instructed!

zentara said...

>   You would have to come and talk to me in person to get the link
>   between this and crop circles, it's kind of complicated, ;-).

Everyone knows that crop circles are a hoax, it has to be because
there /are/ no extraterrestrials.

It was done by people from Atlantis.

-- 
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com


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

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: International crypto restrictions
Date: Wed, 17 Nov 1999 11:37:51 -0500

Peter wrote:
> 
> I have been trying to follow this discussion with regards the use of
> BLOWFISH internationally and still find myself a little confused after
> reading several newsgroups. Please excuse my ignorance if this has been
> raised many times before or is a little basic for this group..
> 
> Is it correct to say that the use of blowfish - limited to say 40bit
> keys - built within an application (for encrypting data files) outside
> of the USA and "written" by a non-us citizen is still subject to the US
> export laws ?.

No -- provided also that it was done without help from US persons
(other than what appears in printed books and documents).

On the other hand, if it was created in the US or with the involvement
of US persons, then it's subject to US laws no matter what the
keylength.

There's a popular misconception that short key ciphers (40 or 56 or
whatever) aren't subject to US export laws.  That's absolutely wrong.
What *is* correct is that they are subject to a different set of
restrictions, but there definitely are restrictions, and processes
for approval of exports, etc.  (All this for US origin stuff, of
course.)

> Are there any problems if the application will never be "imported" into
> the US (in fact have very little to do with the US).

There aren't any restrictions on import of foreign origin crypto
into the US, as far as the US is concerned.  The country of origin
may have something to say about it, though (and the creator's
country of citizenship, if different).
 
> Any help would be appreciated before I begin to program.

Start with http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm.
But you may want to dig further.  For example, "Cryptography and
Liberty" published by EPIC (see http://www.epic.org/bookstore/).
And checking with the export control authorities of your country
is likely to be a wise precaution.

        paul

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

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Ultimate Crypto Protection?
Date: Wed, 17 Nov 1999 11:27:34 -0500

"Douglas A. Gwyn" wrote:
> 
> HJS wrote:
> > But only by 'practical cryptanalysis' i.e. theft, and not by
> > pure cryptanalysis.
> 
> Nope.

Well, you're not going to get very far by asserting a claim
that OTP systems, without pad reuse, were broken, unless you
back up that assertion with an explanation.  Shooting down
other people's guesses without contributing any information
doesn't help convince anyone that there is merit to your assertion.

I can make various other guesses (like: "excessive bias in 
the supposedly random data on the pads"), but you may react
to that too by saying "nope" so I'm probably just wasting my
time.

        paul

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

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 11:45:27 -0500

Tim Tyler wrote:
> 
> After reading the recent contributions to the "SCOTT16U SOLUTION ON THE
> WEB" thread in this forum, I was disturbed to find that a number of
> sci.crypt subscribers were /still/ towing the party line that the AES
> block cyphers might have some security value - *despite* the efforts of
> David Scott to explain exactly why they should be considered insecure.

Quoting Mr. Scott is probably not an effective way to start an
argument, if you want to be taken seriously.

> The problem is simple: the AES cyphers are fixed 128-bit block cyphers.
> The encode identical blocks in the same way.  For certain types of
> message, this is a complete security disaster.

Right, that's why ECB is not normally used.  True for any block cipher.
Not an issue, all competent crypto users know this and avoid it.

I'd suggest you get Bruce Scheier's book and study it.  That'll be
an effective way to get you started on the basics of cryptography.

        paul

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

From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Wed, 17 Nov 1999 11:19:43 -0500

[EMAIL PROTECTED] wrote:
> 
> We have developed a prototype Encryption system which runs 3DES at 1
> GBits/sec ...
> If you are a manufacturer of high speed switches, or have general interest
> in this area or a venture capitalist, you can contac us at:
> 
> [EMAIL PROTECTED]

Are you real, or are you just playing mind games with the
audience?  If you are real, you should consider responsing to
the email you're soliciting.  (And you might want to consider
getting a more professional looking email address...)

        paul

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

From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: "Compressible Encryption" - Is it an oxymoron?
Date: Wed, 17 Nov 1999 10:16:04 -0700

The "compressible encryption" is nothing more than a simple substitution
cipher. It is a joke.  Imagine, a Microsoft security measure is a joke!!
This is "Pre-School" encryption to borrow an idea from Bruce Schneier.

This cipher will not even keep your little brother from reading your
mail.

Alas, the second option for encrypting PST files is not much better
because the password protection can be easily removed from these files.  

Please check out our web site at http://www.crak.com for details and
software which accomplishes this function.

JK   Http://www.crak.com

Paul Mullen wrote:
> 
> As you are probably aware, the default setting for Microsoft Outlook
> personal folder files is "Compressible Encyption", with alternatives of
> better encyption and no encryption.  I can understand that a good
> encryption system would leave a quasi random jumble of bits with no
> discernable pattern and therefore no possibility of compression.  I
> would assume that "compressible encryption" would leave patterns much
> like the original file and a brief glance at an Outlook file confirms
> that there are such patterns.
> 
> The question therefore arises: just how weak is the default
> encrpyption?  Is it so poor (such as a simple transposition cipher, or
> even just an XOR) as to not be worth having?

-- 
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com

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


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to