Cryptography-Digest Digest #789, Volume #11 Tue, 16 May 00 14:13:01 EDT
Contents:
Re: Unbreakable encryption. (Eric Lee Green)
Re: Is OTP unbreakable? (Eric Lee Green)
Re: Fradulent "Cyberscrub" statements regarding Evidence Eliminator Software ("Neo")
Re: Encryption of graphics by transposition (wtshaw)
Re: Definition of "Broken" Cipher (wtshaw)
Re: Is OTP unbreakable? (Simon Johnson)
Re: Problem with DES function (Runu Knips)
Re: Strength of MASKED CipherText found ... (wtshaw)
Creating a good key-shedule (Simon Johnson)
Re: AES Comment: the Hitachi patent (wtshaw)
MD4 extension (fork)
Diffie's Randomized Stream Cipher (Andru Luvisi)
Re: Generator for ElGamal? (David Hopwood)
Re: Strength of MASKED CipherText found ... ("C. Prichard")
Key generation (PBanaugh)
NIST release's final NSA report on AES HW performance (DJohn37050)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: Is OTP unbreakable? (Mok-Kong Shen)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: What is a good Encryption program?? ("C. Prichard")
Re: Key generation ("C. Prichard")
Recommend traffic analysis references. (Was: Mixmasters encrypt how?) (William
Rowden)
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Tue, 16 May 2000 15:20:39 GMT
"C. Prichard" wrote:
> Rather than distibute new masks for each message, its simply necessary to associate
>a mask key to create a somewhat unique mask.
Sigh. Simple XOR? That was breakable a hundred years ago.
There are standard terminology, techniques, and attacks. Learn them, then get
back to us. The sci.crypt faq, posted once a month, has a large reference list
of books to read before you can consider yourself "educated" in cryptography.
You should at least read a couple of those before making a fool of yourself in
this group -- or at least display some humility about the (lack of) knowledge.
Lord knows I made a fool of myself plenty of times in the past, but was not
ashamed to say that I knew little about cryptography and was having trouble
understanding a concept or whether a certain technique was secure or not.
Some key words or terms to think about:
whitening
public key encryption
key exchange protocols
replay attacks
chosen plaintext attacks
salt
challenge
...
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Tue, 16 May 2000 15:28:32 GMT
Simon Johnson wrote:
> to the one obove). Encrypting with a OTP is pointless simply because
> now you now have to figure out a way to secure the OTP key!!!!!!!
Which points out why OTP's are not practical in most real-life situations.
Very few situations call for a courier with a sealed briefcase handcuffed to
his wrist and armed agents protecting his back. Thus the key material is
subject to interception (think about someone casing the post office, unsealing
your package, making a copy of the key material, then re-sealing your
package), not to mention other usual O(1) attacks (eg., bribing the keyclerk
to insert a certain data stream as the OTP, or to give you a copy of the OTP).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: "Neo" <{Boystownboy}@{Bigfoot.com}>
Crossposted-To: alt.privacy,alt.security.pgp,comp.security.firewalls
Subject: Re: Fradulent "Cyberscrub" statements regarding Evidence Eliminator Software
Date: Tue, 16 May 2000 15:29:31 GMT
"Hiram Yaeger" <no@email> ...
|
| Out of curiousity, why do you feel the need to post this spam here? You
use
| a spam filter on your email address, as though it were something you
wished
| to avoid, and at the same time you propagate it here.
|
| If this is the kind of character you have, I wonder how the programmer
| fares.
Some of us appreciate the information........ if you don't then use your
killfilter.
--
Neo
Paranoids Anonymous Member
(DON`T tell them I`m here)
Get the FAQs
http://web2.airmail.net/buzz/faqlinks.html
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encryption of graphics by transposition
Date: Tue, 16 May 2000 09:20:42 -0600
In article <[EMAIL PROTECTED]>, Paul Koning
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > Something simple like a large black circle in the middle of a white field
> > illustrates what I am talking about; a rough pattern of the blocks will
> > tend to include the same ciphertext for all white areas, a different
> > characteristic ciphertext for all black areas, and mixed results for
> > blocks on the boundaries.
>
> That's a very nice example to illustrate the rules that ECB
> must never be used.
>
> paul
It is an argument that you must keep your eyes open for applicable
strength and unacceptable weaknesses. As, in another thread, strength and
weakness are complicated concepts, and must be evaluated in context of the
job to be done.
Figuring that AES is *the* answer, and that algorithms should not be
considered or modified to specific end use, ignores reality. I argue for
putting things in prospective, not making false assumptions that a one
algorithm-fits-all attitude will solve probelms that are not addressed by
it.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Definition of "Broken" Cipher
Date: Tue, 16 May 2000 09:09:20 -0600
In article <[EMAIL PROTECTED]>, Paul Koning
<[EMAIL PROTECTED]> wrote:
>
> I think the reasoning goes like this: attacks only get better over
> time. Therefore, *any* weakness is an opportunity for ever more
> efficient attacks. Therefore, the prudent standard is "there exists
> no known attack better than brute force search of the keyspace".
>
This sounds good, but the idea that keyspace is a simple monolith for each
algorithm is bogus, since it may often be more or less user defined;
sometimes potential keyspace, much of which is likely not to be used, can
be truely monumental.
As for weakness, it is an arm wrestling contest between the cryptographer
and any potential attacker. It matters more that the attackers do not find
weaknesses that that the cyrptographer magically does not include any.
Much of cryptography is qualitative, in that deception is more powerful
than good mathematics, although figuing that you adversary is dumb may be
an act of strupidity on the part of the designer or user.
So, weakness, like strength for algorithms, is as elusive. I continually
turn the search for weaknesses on its head and look for what makes
strength., as it seems to me that this is as important a search as the
other. How can you justify one without the other?
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Tue, 16 May 2000 15:54:43 GMT
In article <8fr8dc$iqu$[EMAIL PROTECTED]>,
"Will Critchlow" <[EMAIL PROTECTED]> wrote:
> "Simon Johnson" <[EMAIL PROTECTED]> wrote in message
> news:8fr420$j1o$[EMAIL PROTECTED]...
> > The only information that can be recovered from the cipher-text is
the
> > length. The fact the output is random means it contains no
information,
> > therefore it has no redudancies that can be analyised.
>
> Kind of irrelevant (I find it interesting). In information theory, a
random
> sequence actually contains *the most possible* information for a
string of
> that length (see for example, Feynman's Lectures on Computation).
>
> Information is defined in terms of the 'surprise' that you experience
in
> receiving the next bit given all the ones that have gone before (or in
other
> words, how well you can predict what's coming next).
>
> In English, for example, you will almost always see a q followed by a
u
> whereas in a random sequence you are as likely to see a q followed by
a t...
>
> As I said, not relevant....
>
> W
>
> --
> ========================================
> B5 New Court, St. John's College
> Cambridge. CB2 1TP
> 01223 522561
> ICQ: 51747953
> ========================================
>
>
Now that is intresting, i wouldn't think random data had the maxmium
possible information density, though it seems logical come to think of
it.
Lets consider compression, the amount of data is reduced, but it
contains more information, and the 'Surprise'factor, of course,
increases. Although, it still has no redudances making my original
statement correct.
Thanxs, that's really quite thought provoking :)
--
=======
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 16 May 2000 17:56:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Problem with DES function
Karim A wrote:
> well, I'm a newbie in encryption and I'm implementing the DES algo.
Just don't. DES is dead.
> But I encoutered a problem in the function of a DES round.
> I have to perform a XOR between a 48 bits subkey and a 48 bits expanded data
> block. Due to my data types I'm using, I don't know how to perform the XOR
> logical operation.
Then you don't know what XOR is.
> In fact, in my program a subkey is an array of 8 bytes, but I IGNORE the two
> last bits to obtain 48 bits sub key and my data block is a "real" 48 bits
> data block, I mean it's an array of 6 bytes. How can I perform the XOR op
> according to my configuration ???
Where is the problem ? XOR works bitwise - just apply it to every
subelement
of your data:
for (i = 0; i != 6; ++i)
c[i] = a[i] ^ b[i];
or Turbo Pascal:
for i := 0 to 5 do
c[i] := a[i] xor b[i];
Btw, you should better use something like the 'long long' of
gcc to get efficient code. Working on bytes is REALLY slow.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Strength of MASKED CipherText found ...
Date: Tue, 16 May 2000 09:49:54 -0600
In article <QGcU4.101$[EMAIL PROTECTED]>, "C. Prichard"
<[EMAIL PROTECTED]> wrote:
>
> 96*95*94*93*92*91*90*89*88*87*86*85*84*83*82*81 =3D 1.385616 E+31
>
96!/80! = .....
But, figure that someone will try to work out these values, then, divide.
--
Secrets that are told or available are not secrets any more, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Creating a good key-shedule
Date: Tue, 16 May 2000 16:11:52 GMT
I've been trying to magic up a 32 round Fiestel-type block-cipher for
some time now, (although its prolly very poor.)
As a bit of background i'll detail the parts of the algorithm.
The Cipher has a 16-bit block length and a varible length key, 0 to 32
bytes.
The F-function seems to do what i want. It takes 2 8-bit words and
reduces them to 1 8-bit word with apperently 'random', i use that word
loosely, distrubution. Although it has undergone next to no analyis.
I'm stuck on the concepts behind a good key shedule, here is what i was
thinking:
Load the key into a 32-byte array, If the key is too short, contatenate
it to fill the array. Then use the 1 byte per round.
This is poor, any suggestions?
=======
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES Comment: the Hitachi patent
Date: Tue, 16 May 2000 09:37:50 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> 68K programables.
Should have been 68xx programables. Strangely, these chips might have
been also erraseable except for the addition of a windowless top. I
suppose that that was the only set of specifications and working plans
that they might have had, however obtained.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: fork <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: MD4 extension
Date: Tue, 16 May 2000 12:32:47 -0400
Does anyone have test vector for the MD4 extension described in RFC1186
?
Thank you.
=================
Daniel Léonard (aka fork)
Computer Science Student
Université de Montréal
"The nuclear warhead is one of the Humans' most efficient weapons. They
first tested it on themselves, obliterating several entire cities. The
intervening centuries since the weapon's first use had not dimmed its
effectiveness, as the Black Star proved when it blew apart. It was, from
all accounts, a most impressive display and took - by the standart of
such thing - quite some time as one section after another after another
of the ship erupted."
- Emperor Londo Mollari, Babylon 5 : In the Beginning
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Diffie's Randomized Stream Cipher
Date: 16 May 2000 09:38:21 -0700
On page 419 of the 2nd edition of Applied Cryptography, Bruce Schneier
mentions a scheme invented by Whitfield Diffie where you send someone
2^n random bit strings, and then the message xored against one of
them. The key is an n bit value which specifies which one. He says
"Any attack must examine an expected number of bits which is in
O(2^n). Rueppel points out that if you send n random strings instead
of 2^n, and if the key is used to specify a linear combination of
those random strings, the security is the same."
Am I correct in understanding this to mean that if I use a 128 bit
key, and for every plaintext byte I send 128 random bytes, along with
the xor of the ones selected by the 1 bits in the key and the
plaintext byte (129 bytes in total), the result is a 128 bit cipher
against which brute force is guaranteed to be the best attack?
Also, does anyone know how important the randomness of the random
parts is?
If so, I could see some value in this scheme. Obviously it wouldn't
be practical for linking VPN segments, but for the occasional
sensitive email, it might be quite useful to have a known security
level in one's algorithm.
It could also be of value to our friends across the pond, as it
provides a great place for tons of random data to be laying around.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
Date: Tue, 16 May 2000 17:26:14 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Generator for ElGamal?
=====BEGIN PGP SIGNED MESSAGE=====
lcs Mixmaster Remailer wrote:
>
> > g does not have to be a generator; however it should not just be random.
> > Ideally g should generate a subgroup of prime order, where the order
> > is large enough to prevent a square-root attack (say 2^180 or 2^200).
>
> Even that is not enough. "Classic" ElGamal encryption outputs g^k, m*y^k
> where k is random, y is the public key, and m is the message. Chances are
> m is not in the subgroup. You may be able to learn information about m if
> (p-1)/q has small factors (where q is the group order).
True, but "classic" Elgamal in Z*_p is not semantically secure anyway,
regardless of the factorisation of p-1 or the choice of g. If it is required
to prevent an attacker from learning any information about the plaintext,
then the appropriate response is to use another DH-based scheme that is
semantically secure (e.g. DHAES); changing the p and g parameters alone
is not sufficient.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOSDIbTkCAxeYt5gVAQE8xAf/RrYppjDqCHxk6U8tOJKJq74NPdDTTAAt
KLLmOn9PiND8wy7II5Gazpn0uHw7Fgo52bMTB31CYMVxJ+NlzY3d24m8aImszTSc
zwU3//Cd3u9mAKv49uCJDZouveAlmqTRlLA7rW4l3hf/Q/shEOgqQ1Rv09WOy5uL
WLTlLiA/hJ5aCgh1vJOnfNF3dDuPa8aD/rwGS4CdUNtXVJpZXxu/+4THRvmSB58v
sA3Pu1tSRdYvJLNELlVxFtjTNRgnj9pFviYWOC3eP+xykiL3/k5H1z78Y9zSJ3IZ
d9PnMhY/MH2/2F4sowYBPoiquPa0YiB5JZ5WMAq+NNB5MmTyQXC11w==
=JK7v
=====END PGP SIGNATURE=====
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Strength of MASKED CipherText found ...
Date: Tue, 16 May 2000 17:00:36 GMT
> 96!/80! =3D .....
THANKS.
-Charles Prichard
------------------------------
From: PBanaugh <[EMAIL PROTECTED]>
Subject: Key generation
Date: Tue, 16 May 2000 13:05:58 -0400
Anybody know of a good way to generate a pseudorandom key from a user's
passphrase?
Here's my idea. Let me know how good or bad this is...
1) Get a passphrase P.
2) Hash P with SHA-1, giving result H.
3) Use H as a key for RC4.
4) Call RC4 1024 times, but don't use it to encrypt anything -- store
the keystream as array M.
5) Use MD5 to hash M, giving K.
6) Use K as the key for IDEA. Call RC4 eight more times to generate an
initialization vector, if necessary (ie, to start cipher block
chaining).
The idea is to transform the passphrase into a key that is as random as
possible. Real real numbers can't be used because they cannot be
re-generated (at least not if they're truly random) in order to recreate
the key for decryption.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: NIST release's final NSA report on AES HW performance
Date: 16 May 2000 17:08:22 GMT
NIST released on 5/15/2000 the final NSA report on AES finalist performance.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Tue, 16 May 2000 19:25:16 +0200
Runu Knips wrote:
> John Savard wrote:
> > It does appear that many others seem to have the approach of not
> > putting anything in a cipher that they don't understand...
>
> Its pretty pointless if you use something you don't understand,
> isn't it ?
I suppose one could interpret 'understand' in this context with
'completely understand'. Sometimes there could be 0.5 or 0.75
understanding without one's really conscious of that (I suppose
everyone has such experiences) and that could be particularly
dangerous in crypto undertakings. Thus to be conservative
(or old-fashioned) doesn't seem to be a bad idea in crpto designs.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Tue, 16 May 2000 19:25:04 +0200
Will Critchlow wrote:
> "Simon Johnson" <[EMAIL PROTECTED]> wrote in message
> > The only information that can be recovered from the cipher-text is the
> > length. The fact the output is random means it contains no information,
> > therefore it has no redudancies that can be analyised.
>
> Kind of irrelevant (I find it interesting). In information theory, a random
> sequence actually contains *the most possible* information for a string of
> that length (see for example, Feynman's Lectures on Computation).
I suppose an analogy of this would be a coin that has two different sides.
Depending from which side you regard it, it appears different but it is
the same coin. You could think that because one combines the plaintext
with xor with an arbitrary string containing the most possible information
that it is most difficult for the opponent to retrieve from the resulting
ciphertext the original plaintext. Consider the case where one xor the
plaintext with a string of all 0's (containing no 'information') and the
above should be clear.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Tue, 16 May 2000 19:25:22 +0200
Simon Johnson wrote:
> Now i would have thought that having pesudo-random s-boxes would be a
> good idea, simply because the attacker has no idea of the strength of
> them, they could be strong they could be weak the attacker know no
> different. Is this a safe assumtion to make?
Not because the opponent has no idea of the 'strength' of the S-boxes,
but because the opponent has no idea of the 'contents' of the S-boxes.
M. K. Shen
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: What is a good Encryption program??
Date: Tue, 16 May 2000 16:57:28 GMT
A program that uses more than E +40 cipher combinations is good =
encryption, but E +63 is even better.=20
FYI: 56 bit DES is about E +19. 128 bit DES is E +38.
-Charles Prichard
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Key generation
Date: Tue, 16 May 2000 17:19:40 GMT
I wrote this Perl module for CipherText last night. The keys returned =
are in the range 0x20 to 0x7f and compatible with my cipher. You can =
modify the value in $key =3D int(rand(96)); to 256 and set the number of =
loop iterations and use it with any cipher.
The get_mask method now returns a set of 1024 values created by the =
build_mask method.
=20
MASK is part of a very practical solution that allows E +40 encryption =
into the default HTTP protocol.=20
=20
# CipherText::MASK.pm;
#
# Charles Prichard 00-05-15
#
# Builds a 1024 byte mask for CipherText.
#
# EXAMPLE:
# ENCRYPTION
# $mask_key =3D '12345678';
# use CipherText::MASK;
# use CipherText::CipherTextII;
# $params =3D "MODE=3DLEVEL II;KEY=3D".$userkey;
# $CTXT2 =3D new CipherText::CipherTextII( $params );
# $MSG =3D $CTXT2->encipher($MSG);
# Message ciphered with userkey.
# $CTXT =3D new CipherText::MASK();
# $params =3D "MODE=3DLEVEL II;KEY=3D".$mask_key;
# $CTXT2 =3D new CipherText::CipherTextII( $params );
# @mask =3D $CTXT->get_mask(); #this will just be get_mask returning an =
array.
# foreach $_ (@mask){ # This work-around for escaping characters.
=20
# $mask .=3D chr($_);
# }
# $mask =3D $CTXT2->encipher($mask);
=20
# (1024 byte MASK is ready)
# $params =3D "MODE=3DPGP;KEY=3D".$mask;
# $CTXT2 =3D new CipherText::CipherTextII( $params );
# $MSG =3D $CTXT2->encipher($MSG);
# $MSG has now been encrypted with base-key-altered 1024 byte MASK.
# MASKED output now has greater diversity than normal CipherText.
# DECRYPTION is identical except that 'decipher' is used rather than =
'encipher.'
package CipherText::MASK;
$CipherText_MASKPackage =3D "CipherText::MASK";
$CipherText_MASKPackage::Version =3D 000515;
$::MASK =3D $CipherText_MASKPackage;
# Reserve MASK in the main namespace
*MASK::=3D\CipherText::MASK;
#################################################
# Sub new #
#################################################
sub new(){
=20
my $self =3D shift;
=20
$self =3D bless {};
$self;
=20
}
#################################################
# Sub build_mask #
#################################################
sub build_mask(){
=20
my $self =3D shift;
=20
$self{'MASK'} =3D "";
my $key;
=20
my @mask =3D ();
=20
for(my $x=3D0; $x < 1024; $x++){
=20
$key =3D int(rand(96));
=20
$self{'MASK'} =3D ($key + 0x20);
=20
push @mask,$self{'MASK'};
=20
}
=20
return \@mask;
}
#################################################
# Sub get_mask #
#################################################
sub get_mask(){
=20
my $self =3D shift;
=20
my @mask =3D =
(63,55,79,72,41,83,114,71,57,82,100,79,37,70,77,95,36,38,121,115,52,114,1=
18,73,92,110,104,53,44,89,110,47,127,110,58,122,107,55,115,96,98,77,125,6=
0,48,74,43,84,81,87,112,48,35,102,101,56,64,119,87,75,103,114,97,108,126,=
72,120,34,61,116,107,35,62,43,43,72,72,110,86,96,68,83,78,37,105,119,77,1=
02,105,108,43,40,64,84,47,113,123,67,103,127,124,109,113,33,120,70,95,89,=
115,88,115,37,109,100,110,119,78,74,60,98,99,65,35,75,54,122,100,50,87,11=
5,63,61,87,102,42,104,63,43,68,99,43,51,119,71,127,105,38,58,107,104,43,8=
8,125,65,56,127,60,98,87,62,85,37,86,89,84,111,66,36,68,32,64,106,58,85,6=
1,37,46,59,104,116,110,98,93,86,74,77,127,65,119,117,107,72,93,124,89,95,=
103,92,52,65,121,99,119,34,33,119,77,127,83,103,97,86,54,82,66,72,127,61,=
102,57,33,32,47,61,88,82,114,72,90,41,36,107,117,102,100,108,82,122,91,11=
7,74,84,119,66,54,119,83,87,84,65,57,99,36,121,57,76,53,87,40,126,42,89,3=
3,44,51,85,94,89,81,105,101,35,49,126,109,73,84,119,53,45,37,126,91,102,1=
27,124,78,35,65,116,56,88,102,117,37,108,112,82,122,41,55,114,84,72,42,56=
,33,43,72,127,55,116,78,82,45,89,69,107,125,110,114,40,95,94,80,48,119,11=
7,106,117,36,44,79,44,91,94,90,78,74,118,95,35,53,50,115,49,74,100,57,81,=
95,56,92,105,114,103,126,32,37,44,36,109,100,95,87,117,58,33,39,96,61,71,=
88,64,85,46,55,39,73,92,51,96,56,76,89,68,99,87,56,68,108,120,101,67,32,1=
11,64,113,91,74,124,103,40,77,36,88,70,78,97,54,59,37,62,46,57,51,100,61,=
61,35,122,99,49,63,117,83,53,120,47,44,84,83,103,82,85,34,72,115,102,86,6=
0,86,75,115,55,61,123,117,124,111,38,46,49,105,39,35,95,50,125,69,121,57,=
99,82,120,105,102,49,93,99,58,74,52,121,98,40,48,112,68,90,69,44,98,41,95=
,107,40,73,52,44,44,112,43,49,84,64,35,40,125,52,44,127,85,108,91,38,33,1=
17,107,119,69,40,34,60,45,56,89,66,94,83,99,36,115,33,95,53,62,81,94,36,1=
16,83,116,37,115,127,98,90,101,91,63,36,89,100,123,65,95,40,102,82,121,33=
,67,84,92,114,40,45,32,59,67,41,64,103,70,91,61,34,98,43,70,106,86,51,71,=
82,60,49,106,58,64,98,119,51,74,44,45,73,71,38,72,81,109,89,80,85,102,108=
,100,85,114,38,121,32,109,103,33,55,51,90,61,93,52,100,65,41,52,53,71,124=
,51,88,44,103,94,110,114,117,74,45,104,120,79,110,74,43,115,72,66,52,112,=
65,65,44,100,109,106,65,126,44,100,111,85,94,79,45,87,120,43,105,92,88,11=
1,38,120,92,67,38,43,70,51,74,72,34,58,117,98,91,80,55,41,40,92,87,42,92,=
93,86,61,127,61,71,121,77,48,94,80,99,73,126,74,57,38,91,49,48,102,50,85,=
53,92,105,121,53,33,119,127,62,78,80,89,33,100,48,82,87,103,122,91,42,90,=
44,57,127,57,37,69,53,96,78,53,36,35,80,116,88,127,96,120,115,102,43,55,1=
16,119,88,40,35,64,117,99,113,49,123,83,125,116,102,67,83,60,66,49,125,68=
,104,68,43,126,116,42,118,115,52,38,68,106,61,114,73,78,41,49,110,98,34,1=
04,126,106,60,72,65,42,87,70,57,42,73,119,95,96,99,60,69,45,57,117,53,73,=
48,89,101,82,111,85,110,127,42,120,55,91,36,121,110,117,35,71,89,73,43,12=
3,127,36,75,106,104,89,69,91,34,60,48,88,61,86,125,64,86,49,40,89,66,112,=
121,60,32,100,108,58,37,66,37,36,104,65,91,66,108,38,66,47,59,40,74,95,12=
3,81,43,38,97,96,35,114,62,93,84,121,116,119,40,87,44,96,46,102,83,44,111=
,69,102,45,92,75,73,107,59,46,115,34,78,62,97,45,46,62,86,34,48,61,63,42,=
59,73,100,122,122,92,108,51,116,103,49,53,58,76,109,94,47,124,92,87,122,9=
8,127,83,109,42,119,106,100,118,43,52,121,79,42,81,94,64,121,97,100,111,4=
8,76,36,51,92,53,97,80,57,69,36,112,124,43,83,119,88,73,104,54,123,70,99,=
121,33,81,44,82,54,120,74,88,45,110,66,100,36,65,89,101,47,78,126,72,111,=
69,32,121,55,65,83);
return \@mask;
}
1;
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Crossposted-To: alt.privacy.anon-server
Subject: Recommend traffic analysis references. (Was: Mixmasters encrypt how?)
Date: 16 May 2000 17:22:43 GMT
Would someone recommend references that discuss traffic analysis? I'm
asking for references because the Mixmaster protocol has intrigued me
recently, and I'd like more background information for digital mixes.
I think that some readers of sci.crypt (or alt.privacy.anon-server)
might know, but I don't find any references to traffic analysis in the
sci.crypt FAQ.
I have seen mention of these documents so far:
(The Zendian Problem)
* Military Cryptanalytics, Part II, Volume II, Lambros D. Callimahos and
William F. Friedman
* Traffic Analysis And The Zendian Problem, Lambros D. Callimahos
(Digital Mixes)
* "Untraceable Electronic Mail, Return Addresses, and Digital
Pseudonyms", Communications of the ACM 24 (1981) 2, Chaum, D.
* "The Design, Implementation and Operation of an Email Pseudonym
Server", 5th ACM Conference on Computer and Communications Security,
1998, Mazieres, D. and Kaashoek, F.
* "Anonymisierung von Internet-Diensten", Studienarbeit, University
of Hamburg, January 1998, Moeller, U.
(Unfortunately, I can't read German.) Does anyone know of other
sources? Also, if anyone has read any of these, I'd appreciate their
thoughts on what they read (before I send more money to Aegean Park
Press :-]).
--
-William
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
------------------------------
** 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
******************************
