Cryptography-Digest Digest #262, Volume #11 Sun, 5 Mar 00 21:13:01 EST
Contents:
Re: sci.crypt Cipher Contest ([EMAIL PROTECTED])
Re: why xor?(look out,newbie question! :) (Mok-Kong Shen)
Re: sci.crypt Cipher Contest ("Joseph Ashwood")
Re: On jamming interception networks ([EMAIL PROTECTED])
Re: 'Free' services with tokens/puzzles ([EMAIL PROTECTED])
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David
Hopwood)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David A.
Wagner)
Re: sci.crypt Cipher Contest ("Adam Durana")
Re: Oh Look! 208.170.158.15 is an Open NNTP SERVER THAT ALLOWS POSTING TO ANY
NEWSGROUP (Andru Luvisi)
online-Banking: 128-Bit SSL or Java-Applet ? ("Phil")
Re: are self-shredding files possible? (Michael Sierchio)
Re: are self-shredding files possible? ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: sci.crypt Cipher Contest
Date: Sun, 05 Mar 2000 16:18:19 -0800
Why should an entry be a block cipher? Stream ciphers are faster and the
majority of applications are stream ciphers.
Joseph Poe
Adam Durana wrote:
> I see a lot of ideas for encryption algorithms posted to sci.crypt all the
> time, and I know several regular posters have thier own ciphers they have
> developed. Since most of us are amateur cryptographers, and study
> cryptography for fun. I thought it might be fun to have a contest such as
> AES. And at the end we could select the best cipher based on the criteria
> we decide on. So if anyone is interested in participating, we could start
> to draw up the criteria for the contest entries.
>
> The only thing I can think of right now that should be in the criteria is
> that an entry should be a block cipher. Ofcourse other details such as key
> size, block size and etc will need to be decided on.
>
> So if you have any ideas for the basic criteria for an entry post it, and I
> will do my best to keep a record of all the ideas. Eventually we will have
> to decide on a solid cirteria for entries, which will be hard without a
> doubt, but we will see how it goes.
>
> - Adam Durana
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Mon, 06 Mar 2000 01:34:22 +0100
Guy Macon wrote:
>
> I have read (but lack the background to verify for
> myself) that a true random bytestream xor'ed with
> any bytestream not derived from the true random
> bytestream results in a true random bytestream.
>
> Does addition of bytes modulo (2^8) have this same
> property? Is there a reference that I can point to
> if someone doubts this?
>
> Can I extend the idea and add nybbles modulo 16 or
> 16 bit words modulo 65536? For bits I believe that
> xor and addition modulo 1 act the same.
If by 'true random' you mean 'impossibility of being predicted',
then I suppose the proof is straightforward. Let A be any sequence,
B be an unpredictable sequence, and C be their modulo sum, i.e.
C = A + B mod n
Suppose C were predictable. Rewrite the above to
B = C - A mod n
Now the left side is unpredictable, but the right side is predictable.
This contradiction establishes the result.
But I suppose what you read previously is a theorem regarding
distributions. It says that the modulo sum of an arbitrary
distribution and a uniform distribution results in a uniform
distribution. The result is due to Wichmann and Hill who stated
the theorem for continuous distributions in a paper in Applied
Statistics. A rigorous proof appeared later in a paper by
someone else for which I don't have the reference at hand. But
in the discrete-valued case as in the above, one can in fact
prove it rather simply. For illustration, let's consider n=4.
Let a0, a1, a2 and a3 be the frequencies of 0, 1, 2, and 3 of A,
and similary b0, .... and C0, ..... Now we have, for example,
c3 = a0*b3 + a1*b2 + a2*b1 + a3*b0
Since B is uniform, we have
c3 = (a0 + a1 + a2 + a3)/4 = 1/4
Thus C is uniform.
If one considers a continuous distribution to be the limiting
case of a discrete-valued distribution, one can arrive at
the original result of Wichmann and Hill from the above. (The
proof in the other paper mentioned above is a bit more involved,
as far as I can remember.)
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Sun, 5 Mar 2000 16:46:39 -0000
What I'd like to see is different classes of ciphers. Many
of us realize that ciphers are not one size fits all, for
some uses we need stream, or X-bit, or whatever. In taht
vein I suggest the following classes (all are of course
judged on security also):
Block small: chosen for codesize, Target : extremely limited
environments, not speed sensitive
Block medium: chosen mostly for security, weighted by
simplicity and speed on desktop machines, Target: the usual
suspects, communication between desktop machines Example:
DES
Block large: chosen for security, in addition it should have
security properties that will make quantum computers
primarily inneffective Target: long term security
Example:AES
Block Unlimited: Designed for large block encryption,
generally either for disk blocks, or files, example:
Scott19, Mercy
Stream XOR/ADD: The typical realm, primes example is RC4
Stream Advanced Chaining: Uses the pRNG as the key to
another cipher (besides XOR or ADD)
Stream Unlimited: Goes beyond advanced chaining to actually
utilize the input text in the encryption of future blocks.
I don't think the knowledge of public-key ciphers is such
taht they should be included.
As for requirements:
Of course resistance to known attacks.
balanced related-keys, e.g. if one Plaintext,Ciphertext pair
as two possible keys, all Plaintext, Ciphertext pairs have 2
keys
approximately flat probabilities of ciphertext, regardless
of key, or plaintext.
Effective diffusion, if one bit changes the resultant change
is approximately half the size.
Completeness, meaning that for as many plaintext, ciphertext
pairs as possible a key exists
Speed, simplicity, safety margin, etc.
Joe
"Adam Durana" <[EMAIL PROTECTED]>
wrote in message
news:mUBw4.3421$[EMAIL PROTECTED]...
> I see a lot of ideas for encryption algorithms posted to
sci.crypt all the
> time, and I know several regular posters have thier own
ciphers they have
> developed. Since most of us are amateur cryptographers,
and study
> cryptography for fun. I thought it might be fun to have a
contest such as
> AES. And at the end we could select the best cipher based
on the criteria
> we decide on. So if anyone is interested in
participating, we could start
> to draw up the criteria for the contest entries.
>
> The only thing I can think of right now that should be in
the criteria is
> that an entry should be a block cipher. Ofcourse other
details such as key
> size, block size and etc will need to be decided on.
>
> So if you have any ideas for the basic criteria for an
entry post it, and I
> will do my best to keep a record of all the ideas.
Eventually we will have
> to decide on a solid cirteria for entries, which will be
hard without a
> doubt, but we will see how it goes.
>
> - Adam Durana
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On jamming interception networks
Date: Mon, 06 Mar 2000 01:00:19 GMT
Sorry if I've quoted you wrong in my previous post. As it seems, we
mostly agree.
> All messages have the potential of yielding interesting stuffs for
> them. But I fairly doubt that all internet messages are processed
> by them. They may have very huge resources, but the volume of all
> messages is simply too big for them to handle, I guess. That's why
> I speculate that they analyse with priority messages from some
> selected targets and then randomly select from the rest of
> interceptable materials for close study as their resources permit.
Hm, this might be an empirical question that can be decided. I don't know
the relevant statistics but it would be interesting to estimate the
world-wide email traffic based on public statistics, and calculate which
computing power and storage space would be needed to analyse all of this
traffic. Together with estimated financial resources of large agencies
this maybe would give some empirical base on judging wether at all or to
what extent global interception networks can work.
Unfortunately, I don't know enough about the relevant network statistics,
the computing power of known high-performance computers and their cost,
and the estimated budget of intelligence agencies to calculate even some
rough estimates. Maybe somebody knows enough about this to shed some
light on this... not directly related to cryptography, but I think this
could be of interest to many people.
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 'Free' services with tokens/puzzles
Date: 6 Mar 2000 01:01:30 GMT
I am not sure if I follow you here, but it seems to be some sort of
"parasite" attack, that will not kill it's victims but merely drain them of
resources.
I ask myself if such measures would even be illegit. I guess many people would
accept that their network provider did this. Why would anyone otherwise
accept the arrangements that the real service provider offers?
Also, I am not sure that such attack would even be percieved as an attack
against the service provider. It seems more like a security problem every
internet user has to deal with all of the time and cannot demand that a
specific service provider will solve.
In a previous article, "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
>I can easily alter the attack to address that. I take the
>same real client A, place it in my network N. In my network
>N I have the following:
>K other systems that I wish to have access to the resource
>being marshalled by participation.
>NAT a network address translation box, the will map my K+1
>machines to one address.
>[insert extra measures as needed]
>
>I now have access to the resource from K machines that would
>otherwise not have access. Alternately if the resource is
>marshalled by the number of machines perceived, I could
>create a rogue client inside of a NAT box that goes the
>other direction (1 to many), and use K NAT boxes (probably
>inside my K machines) to address the issue. Doing either of
>these I isolate A, or use a rogue A that still performs the
>work.
>
>I have found a rather kludgy solution, that many clients
>won't like. Allow them access to the resource based on the
>amount of work they do, if AOL writes the program into their
>client, and AOL performs 90% of the operations, then AOL
>gets 90% of the resources (since the resources are transient
>it would often not be necessary to place the restrictions,
>but once the pipe is full the cuts could be severe).
> Joe
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
Date: Mon, 06 Mar 2000 01:00:16 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> In article <89u5pg$dlr$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David A. Wagner) wrote:
> > In article <89tu0t$2uc$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > wrote:
> >
> > > It's well known that in some case stream ciphers are vulnerable
> > > to a "meet in the middle known plaintext" attack.
> > > if P xor S = C the attacker that known P can
> > > obtain S and replace P with an arbitrary P'. How is possible to
> > > avoid this problem?
> >
> > First off, this is not what is meant by a "meet in the middle"
> > attack.
>
> Sorry, what's the right name for this kind of attack?
The subject line is correct: it's a special case of a man-in-the-middle
attack. Even though man-in-the-middle covers a wide range of attacks,
I haven't heard it called by any more specific name that that.
(A meet-in-the-middle attack, BTW, is an attack that splits the key
to some keyed function - e.g. a cipher - into two parts, and uses
a collision search to find these parts, with a work factor that is
usually proportional to the square root of the work that would be
taken by a brute force attack.)
> > Second, the right solution is to authenticate the text using a
> > separate crypto-algorithm, usually called a MAC. Favorites
> > includes SHA-HMAC and TripleDES-CBC-MAC.
>
> No, I cant
> A stream cipher is very useful to encrypt a socket in the
> case of a telnet-like connection since if you use a block
> cipher you needs to spent more bandwidth.
Yes, but there's really no secure alternative to spending more
bandwidth (for example by splitting the stream into blocks, each
of which is authenticated, as SSL/TLS does).
> In this case you can not use a MAC since you need that every byte
> reach the destination ASAP.
On packet-switched networks, there is a significant amount of
overhead associated with each packet anyway. Whereever possible
Telnet should be used in line-buffering mode; in that case
the overhead of encrypting and authenticating each line (normally
one per packet) is not very great. Using it in unbuffered mode is
fairly inefficient regardless of whether encryption is used.
Telnet is also an example of a protocol where, for the uses to which
it is typically put, authentication is absolutely essential (and
does need to be applied to every byte). Therefore you have to just
bite the bullet and implement it, and live with any resulting
inefficiency. The problem is not really all that bad; it only looks
bad if you consider the overhead relative to the *payload* size,
which distorts the actual bandwidth and processing costs involved.
> To use some material from the keystream to setup an sbox
> _if it is secure_ is a possible solution? if you scramble
> the sbox every X bytes is even better? The problem is that
> I want to learn from a cryptographer if it is/isn't secure 8)
If a single byte is accepted without having been sent by the
legitimate party, that would be sufficient to cause security problems
that can be practically exploited in many applications.
The only reliable way to be able to reject invalid packets, is for
the authenticated ciphertext of each packet (regardless of whether
it represents one byte or 10KB of plaintext) to contain more
information than the plaintext, by at least some minimum amount.
In practice, this means that it must be longer than the plaintext
after compression.
It's not difficult to show that the ciphertext must be at least n
bits longer than the plaintext (after compression, if used), to get
a 2^-n probability of incorrectly accepting a packet.
The most obvious, and a robust way of doing this is to append a MAC,
with an output length of n bits. In principle it might be possible to
combine the authentication with the encryption for performance reasons,
but previous attempts at doing that (e.g. PCBC, iaPCBC, CBCC) have
not been resounding successes from a security point of view.
- --
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
iQEVAwUBOMMC/jkCAxeYt5gVAQFx2ggAyv/sThkLDX9UwcrjoPJ5fTxhjwkTIU7+
spXAvY0gSZguAJcWYvYKITtskagLY57AqP9jXmFQSMQSFPH4sgFv7++rOKpfcTkq
YI4tnGEOH3JhUi9FuiEiKBkRiAabkcCcQmzWSd89/E7Bc0K5PcRpTQjILy/3hR4E
s3aXW6MzCOd7bhC2mzWDovhzZSSzrhw/BYbJtBflFs5ZrrecUgKaBjpTlmdNWhqL
zn8s+8sQuBKj/VS1bfmnZVZGHk0lGepsd4zF5Su8+XS27J4/Xj70zOubczS3YIcS
bVdcpyj7HWflUPjOncX9Ou2ES/LsoB7tZeu4O+M+vKKmFUUi7fx2hg==
=5eMM
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 5 Mar 2000 16:46:00 -0800
In article <89up6c$h9l$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> I would suggest an error propagating protocol. If you use e.g. WeakCipher
> which based on a "P-CFB" mode (is it really called that?) you will neither
> increase the bandwidth nor have to wait for a signature, and the entire
> message after any altered bit will be complete gibberish. A "bit flipping
> attack" won't work either.
But mere error propagation is not enough.
PCBC mode includes full error propagation, but is not secure
in the contexts the poster was asking for.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Sun, 5 Mar 2000 20:27:06 -0500
I was thinking if people actually participated we could have other contests
every so often. But for the first one I think we need to have one category,
or class as you put it. If this contest goes over well we could have
another one for stream ciphers, or block ciphers depending on which one is
chosen for this contest. Personally I think this contest should be one of
block ciphers, because there has been a lot of work done on block ciphers.
I'm not saying no one studies stream ciphers, because that just isn't true,
but I think there would be more entries and more participation if we went
with block ciphers. You brought up another good point which was that the
ciphers should be secure, and have certain properties. I did not even think
about this because I figured people would assume thier entries should be
secure, but you are right those things should be part of the requierments.
I hope to get a little web page together to keep track of all the
suggestions and start posting drafts of the requierments until as many
people as possible are happy with them. Also if you post suggestions please
include reasons for your suggestions. Saying "entries should be an X cipher
working on X bits with an X bit key size", with no explaination does not do
any good.
- adam
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Oh Look! 208.170.158.15 is an Open NNTP SERVER THAT ALLOWS POSTING TO
ANY NEWSGROUP
Date: 05 Mar 2000 17:19:38 -0800
> Subject: Re: Oh Look! 208.170.158.15 is an Open NNTP SERVER THAT
> ALLOWS POSTING TO ANY NEWSGROUP
I remember when running an open server meant you were a friendly,
neighborly sort of person. Pity the spammers have made running open
servers "stupid". Sometimes I miss the old 'net.
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 |
==========================================================================
------------------------------
Reply-To: "Phil" <[EMAIL PROTECTED]>
From: "Phil" <[EMAIL PROTECTED]>
Subject: online-Banking: 128-Bit SSL or Java-Applet ?
Date: Mon, 6 Mar 2000 02:12:32 +0100
As developer of ecommerce-applications (online-banking related) I have to
evaluate the best method of SECURE TRANSMISSION and USER AUTHENTIFICATION.
The 2 most realistic Alternatives are:
No 1: Java Applet solution with 128-Bit encryption (maybe with port-hopping)
No 2: 128-Bit Browsers (now available even outside of the US.)
User Authentification in both cases with digital signatures (certificates),
issued by official authorities or banks.
The biggest advantage of No. 2 are costs: Programming large Java solutions
is far more expensive than using SSL.
QUESTION:
- What advantages / disadvantages does 1. / 2. have ?
I appreciate your help,
Phil
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Sun, 05 Mar 2000 17:44:34 -0800
Joseph Ashwood wrote:
> You obviously don't do much programming, at least none
> security related.
I see no future in communicating with someone who compounds
ignorance with arrogance. <PLONK>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: are self-shredding files possible?
Date: Sun, 5 Mar 2000 18:07:34 -0000
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
For those of you still reading, if you look through the
sci.crypt history you will find that this has been discussed
many times, and the ending every single time is that no
matter what OS you use, the security can be violated.
Joe
p.s. in case Michael happens to still be reading, the
feeling is mutual. Good to see we agree on something.
"Michael Sierchio" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
>
> > You obviously don't do much programming, at least none
> > security related.
>
> I see no future in communicating with someone who
compounds
> ignorance with arrogance. <PLONK>
------------------------------
** 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
******************************
