Cryptography-Digest Digest #260, Volume #11 Sun, 5 Mar 00 18:13:01 EST
Contents:
Re: 'Free' services with tokens/puzzles ([EMAIL PROTECTED])
Re: On jamming interception networks (Mok-Kong Shen)
Re: why xor?(look out,newbie question! :) (Guy Macon)
Re: Assistance needed (pink aka Chr. Boesgaard)
Re: very tiny algorithm - any better than XOR? (David A. Wagner)
Re: very tiny algorithm - any better than XOR? (David A. Wagner)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David A.
Wagner)
Re: very tiny algorithm - any better than XOR? (Carl Byington)
Re: very tiny algorithm - any better than XOR? (Carl Byington)
Re: Crypto.Com, Inc. (Xcott Craver)
Re: are self-shredding files possible? (Dave Howe)
Re: are self-shredding files possible? ("Joseph Ashwood")
Re: are self-shredding files possible? (Michael Sierchio)
Re: are self-shredding files possible? (Michael Sierchio)
Re: RC4 and salt (Tom St Denis)
Re: are self-shredding files possible? ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 'Free' services with tokens/puzzles
Date: 5 Mar 2000 20:09:36 GMT
You are right, but such attacks are, in a sense, a smaller problem since it
is in the best interest of the clients to avoid them. Consequently, the
service provider will in this case not have to come up with a protocol which
is tamper resistent even though it is open source and explained in detail. I
guess a conventional digital signature scheme would be as good as any
solution. (Unless A has only made contact with B from the start, but if this
is so A must either be really stupid or probably sooner than later break all
contact with B.)
In a previous article, "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
[---]
>In addition I realized that both of our methods are subject
>to a man in the middle attack, as follows:
>download real software on client A
>create fake software on client B
>make A think B is the server
>Whenever A talks B routes the data to the server
>Whenever the server talks B filters it and sends the data to
>A
>Whenever B wishes to use the connection B sends to the
>server.
>
>If you want to avoid attacks like this, then neither of the
>proposed methods will work.
> 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]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Sun, 05 Mar 2000 21:32:37 +0100
[EMAIL PROTECTED] wrote:
>
> > In one previous follow-up I have remarked on some other people's
> > suggestions on the internet in the past (I read many times
> > such suggestions) of intentionally putting words such as 'bombs'
> > in e-mails in order to 'waste' the resources of the interception
> > agencies and hence block these. (There was last year even an
> > action asking people to do that on a particular day.) I argued why
> > that is not useful to achieve the intended purpose. For those at
> > the agencies are certainly not unintelligent. They 'must' know
> > that no terrorist, unless he is a fool, would ever write such words
> > in plaintext in his messages to his companions. Thus I conjecture
> > that there is even a possibility that they in fact put such key words
> > in a 'negative' list to sort out from the outset stuffs that are
> > uninteresting. A person shouting lourdly in the street that he is
> > going to rob a bank is certainly and definitely not a gangster but
> > rather a candidate for the psychiartric clinic. Do you see my point?
>
> Would be nice, but it's not logical. If you were right, it always made
> sense to put words like "bomb" in the mails. If they were on the
> exclusion lists, I would not be surveilled. If they were on the inclusion
> lists, we would jamm the interception network. I don't think that simple
> keyword triggered lists are used at all. If anyone wants to surveille
> large communication networks, there are more sophisticated tools to do
> that.
If you consider the context that I formulated the sentence, you
would see that I was maily against the thesis that such key words
play a very essential (the primary) role in determining which
messages should be closely examined. To assert in the opposite
direction, namely that such key words play a very essential role
in determining the exclusion from examination would in fact be
'non-logical' if the first view is accepted. The key words play
some role, but fairly minor in my conviction. I certainly agree
with you that they use more sophisticated methods. But I suppose
that this is critical in case they are randomly picking some
messages to examine. Targets that are considered to be sources of
fruitful results are certainly much more carefully monitored and
more human resources would be expended on these in addtion to
purely 'mechanical' means.
>
> But I also don't think that terrorists don't use words like "bomb" in
> their mails. Terrorists, criminals and so on, often have a "support"
> community--- a network of people acting semi-legally or plain legal and
> in one way or other have to do with the few "active" terrorists. These
> people will sometimes use plain text messages without any "code words".
> And collecting information is then combining many pieces of a puzzle
> until you can draw some conclusions. That's why I think analysis of
> normal, unencrypted communication can be very interesting to various
> agencies.
Man is creative. Inventions often result from some big necessities.
If some paths of communications don't funtion, some others would
be found. Fairly off-topic in the present context, but maybe
nonetheless of some interest is what someone told me about a
subtile method with which a member of a large gangster group
'authenticates' himself to another member of the group who is
yet personally unknown to him but who runs a restaurant. He comes
to the restaurant as a customer and, after the boy has placed
knifes, forks and spoons before him, reorders these in a certain
particular fashion such that the restaurant owner could identify
his membership. This is certainly a small and trivial story. But
it does help to illustrate the 'creativity' of humans in certain
situations. One sees how entirely ineffective and hence useless
it could be, if the bureaucrats want to suppress export of strong
crypto through regulations like EAR or the Wassenaar Arrangements.
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.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: why xor?(look out,newbie question! :)
Date: 05 Mar 2000 15:28:02 EST
In article <89u7ij$94j$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>Right, this is a stream cipher, if your Pseudorandom
>Number generator is secure your stream cipher will
>be secure.
>In this context to use xor or to use add mod 256
>is the same from the security stand point.
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.
------------------------------
From: [EMAIL PROTECTED] (pink aka Chr. Boesgaard)
Subject: Re: Assistance needed
Date: 05 Mar 2000 21:28:48 +0100
[EMAIL PROTECTED] (Nemo psj) writes:
> Ok i'll explain the algy i have come up with.
>
> Oh and i'm still looking for some source to a proven secure encryption scheme
> to help in making mine much better than what it is write now and solve my
> pattern problem.
For an implementation of RC4 check:
http://www.diku.dk/users/pink/pcrypt.cc
It's implemented from the description in Applied Cryptography (but not
tested for correctness).
There is no fancy API or anything, but actually RC4 is pretty simple
-- check out Applied Cryptography and you should be able to implement
it yourself without any trouble.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 5 Mar 2000 12:14:46 -0800
In article <89q8lm$3n7$[EMAIL PROTECTED]>,
Carl Byington <[EMAIL PROTECTED]> wrote:
> void decrypt(word8 *k, word8 *v)
> {
> int i, j, r;
> for (r=3; r>-1; r--) {
> for (i=6; i>-1; i--) {
> for (j=3; j>-1; j--) {
> // feistel network v[i], v[i+1] form the 16 bit block
> // L = v[i]
> // R = v[i+1]
> word8 t = v[i];
> v[i] = v[i+1] ^ ((rotate_left(t) + k[r*4+j]) & 0xff);
> v[i+1] = t;
> }
> }
> }
> }
This has diffusion problems, if I understand the code correctly.
Change the first byte of the plaintext, and watch what gets affected.
After the first `round' (r=3), the first two bytes change.
After the second `round' (r=2), the first three bytes change.
And so on.
After all four rounds, only the first five bytes of the ciphertext
will be affected by the first byte of the plaintext.
That's a pretty bad property for a modern cipher to have. :-(
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 5 Mar 2000 12:19:44 -0800
In article <89s1ak$sfu$[EMAIL PROTECTED]>,
Carl Byington <[EMAIL PROTECTED]> wrote:
> If that is possible, so we have SBOX[] as a 256 byte array,
> what do you suggest for a replacement for my current
> v[i] = v[i+1] ^ ((rotate_left(t) + k[r*4+j]) & 0xff);
> Something like:
> v[i] = v[i+1] ^ SBOX[((rotate_left(t) + k[r*4+j]) & 0xff)];
> or:
> v[i] = v[i+1] ^ (SBOX[t] + k[r*4+j]) & 0xff;
Either of the latter two look much better than the first.
The rotate probably doesn't buy you anything, I'm guessing,
so if it costs you a cycle, leave it out, and use that cycle
to up the number of rounds instead.
One recommendation: I'd suggest adding i into the mix above
somehow, to prevent slide-like attacks. e.g.,
v[i] = v[i+1] ^ SBOX[(t + k[r*4+j] + i) & 0xFF];
but the exact mechanism probably doesn't matter too much.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 5 Mar 2000 12:28:09 -0800
In article <89udhd$d58$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Sorry, what's the right name for this kind of attack?
I don't know. I've sometimes informally used the term
`bit-flipping attack', but I don't know if there is any
standard accepted name for this type of attack.
> No, I cant [... use a MAC ...]
> 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.
Ok. Let me just say up front to prevent confusion that
you can still use a MAC without using a block cipher.
(I think you probably knew that, and mentioned block cipher
only by way of example to illustrate the point that this
must be immediate delivery of each byte, but I wanted to
mention it just in case.)
> In this case
> you can not use a MAC since you need that every byte reach
> the destination ASAP.
Ok. You've got a very hard problem on your hands then.
One problem with the slightly more general combiner scheme
you mentioned (C = Sbox[P] xor K instead of C = P xor K)
is that it doesn't really prevent these types of `bit-flipping
attacks'. The attacker can still flip a bit in the ciphertext
and know that the result will change only a single byte in the
decrypted plaintext.
In some scenarios, this ability may be useful to the adversary,
even if he can't predict exactly how the modified plaintext byte
will change. For instance, imagine a bank sending instructions
electronically ("transfer $000100.00 from Alice's account to
Bob's account"). If you flip a bit in the ciphertext corresponding
to the leading "0" in the plaintext, you will cause the amount
transferred to be increased dramatically from $100 to hundreds
of thousands of dollars. You can imagine that Bob might have
considerable incentive to mount such an attack. It seems to be
true that the attacker can't predict exactly what that leading
"0" will turn into after the attack, but he probably doesn't
care -- no matter what it turns into, Bob will have made a
considerable profit.
I don't know of any general solution to the problem, and it
seems to be quite a difficult one.
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 5 Mar 2000 21:27:30 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <89uf7m$drn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
[snip]
>After all four rounds, only the first five bytes of the ciphertext
>will be affected by the first byte of the plaintext.
>
>That's a pretty bad property for a modern cipher to have. :-(
Yes. Does it help to run R for 8 rounds at the expense of the J loop
which would then only use 2 bytes of key material?
void decrypt(word8 *k, word8 *v)
{
int i, j, r;
for (r=7; r>-1; r--) {
for (i=6; i>-1; i--) {
for (j=1; j>-1; j--) {
// feistel network v[i], v[i+1] form the 16 bit block
// L = v[i]
// R = v[i+1]
word8 t = v[i];
v[i] = v[i+1] ^ ((rotate_left(t) + k[r*2+j]) & 0xff);
v[i+1] = t;
}
}
}
}
Or do we need to use all the bytes of the key material in the J loop?
If the J loop iterates across all 16 bytes of key material, and we use
at least 8 rounds to attain full diffusion, it becomes too slow. We can
run about 3 times slower than the algorithm above, so we could use 12
rounds with 4 bytes of key material in each round.
We can also modify the rotate from the current single bit rotate to a
five bit rotate by adding one instruction if that helps anything. A
four bit rotate (swap nibbles) is smaller than the single bit rotate.
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCVAgUBOMLRNdZjPoeWO7BhAQGbqAQAsfyK9pjegHdOEVJeq8Jq3emQP7JSd9+O
1AALAWgkHYL3F3/bxMULnVOjh3kRprN4YvrB/Qld3tNTuWWdG/+WifEMMLhdPc0P
4HXazz0gSBnaVpy+2BbZ4fNxWs/DUNpRg6zWymauA2SvsBLirikg8RLJglqEtZFN
F9uEAWfVkV8=
=gNzc
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 5 Mar 2000 21:36:32 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <89ufh0$dsc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>In article <89s1ak$sfu$[EMAIL PROTECTED]>,
>Carl Byington <[EMAIL PROTECTED]> wrote:
>> If that is possible, so we have SBOX[] as a 256 byte array,
>> what do you suggest for a replacement for my current
>> v[i] = v[i+1] ^ ((rotate_left(t) + k[r*4+j]) & 0xff);
>> Something like:
>> v[i] = v[i+1] ^ SBOX[((rotate_left(t) + k[r*4+j]) & 0xff)];
>> or:
>> v[i] = v[i+1] ^ (SBOX[t] + k[r*4+j]) & 0xff;
>
>Either of the latter two look much better than the first.
>The rotate probably doesn't buy you anything, I'm guessing,
>so if it costs you a cycle, leave it out, and use that cycle
>to up the number of rounds instead.
>
>One recommendation: I'd suggest adding i into the mix above
>somehow, to prevent slide-like attacks. e.g.,
> v[i] = v[i+1] ^ SBOX[(t + k[r*4+j] + i) & 0xFF];
>but the exact mechanism probably doesn't matter too much.
Can we use the 16 byte key itself as SBOX[16], and then
v[i] = v[i+1] ^ k[(t + k[r*4+j] + i) & 0xf];
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCVAgUBOMLTXNZjPoeWO7BhAQGhvwP/Xgoc/5VUaPaHZO+GEnTVV/s8JP9gel8O
uAuzXbRpZYfhPpW+ahgJdYGq/D/r5jgaNxA2J/PH22F9Gr7xpQD1L8asISLR7dIT
Pj3OPHmkO9d6/RbgCLpBJgiCAYV7M6+etMCYhqu8EvSdPjIXw81lQRHSHt1mya7c
oqOFYo/lbho=
=CU9z
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Crypto.Com, Inc.
Date: 5 Mar 2000 22:00:29 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn wrote:
>
>> It's called "spread spectrum" communications and is a well developed
>> field. It offers advantages in noise reduction as well as privacy.
[etc]
>It is the 'efficiency' of such measures 'in practice' that I suppose
>could be interesting. If the efficiency is indeed very high, then the
>'value' of encryption (in the narrow sense) would be correspondingly
>somewhat lower in my humber view.
Oh, encryption is still very necessary for privacy in existing
spread-spectrum systems. Yes, the spectrum-spreading offers extra
privacy---no more people tapping mobile phone calls with a very
simple receiver---and both sender and receiver must share key
information for the frequency hopping or spreading codes.
It is a form of steganography, parameterized by a key shared
between sender and receiver.
But in practice, as this key data is used in wireless phones,
it isn't intended nor reliable as a secret key. Rather, spreading
codes and such are assigned with robustness to multiple users in mind,
not robustness to eavesdroppers. Also, yer base station can be
tapped. So in real-world, large-scale communication systems,
you must still rely on encryption for quantifiable privacy.
BTW, what you call a "(pseudo) one-time pad," wireless people
often call "Direct-sequence spread spectrum." See, XORing a
message with a random string makes its frequency distribution
very wide, flat and short---it spreads its spectrum. In CDMA
(Code-Division Multiple Access,) a wireless device modulates
its output with a pseudo-random "spreading code," which
spreads its energy over a large frequency range alloted to it.
Again, this isn't real security: the secret key is usually
a short "chip" of pseudoradomness, repeated over the entire
message.
-Caj
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Sun, 05 Mar 2000 22:08:21 +0000
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Mon, 28 Feb 2000 11:36:30
-0500]), Paul Koning <[EMAIL PROTECTED]> said :
>Sure, that's what the PR fluff says. But where's tbe beef? If you
>have a backup copy the message clearly hasn't disappeared. If you have
>a backup copy plus a search warrant, clearly the message will be
>produced
>even if the supposed time period is gone.
>
>The reality is that what's being asked for is impossible. You *cannot*
>create electronic messages that "turn to dust" after some time. The
>best
>you can do is create a set of *procedures* that are uncooperative when
>someone attempts to get the message later, but there are limits to
>how uncooperative you can be when you're up against government power.
If it is the one I am thinking of, you *have* to be online to read it
- the software queries a keyserver someplace on the net to get the
symmetric key needed to decrypt the message; after the deadline, the
keyserver deletes its copy of the key, leaving no way to retrieve the
text.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: are self-shredding files possible?
Date: Sun, 5 Mar 2000 14:30:57 -0000
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
> If it is the one I am thinking of, you *have* to be online
to read it
> - the software queries a keyserver someplace on the net to
get the
> symmetric key needed to decrypt the message; after the
deadline, the
> keyserver deletes its copy of the key, leaving no way to
retrieve the
> text.
But how do you delete my copy of the key?
Joe
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Sun, 05 Mar 2000 14:49:23 -0800
Paul Koning wrote:
> ...If you
> have a backup copy the message clearly hasn't disappeared. If you have
> a backup copy plus a search warrant, clearly the message will be
> produced even if the supposed time period is gone.
You are simply mistaken -- a backup copy, as well as all other deleted
or undeleted copies, is of no avail. Once the expiry time has arrived
the key is securely deleted from the keyserver. A brute force attack to
recover the plaintext is quite infeasible. So, the bits may still be
there, but the DOCUMENT has disappeared. No court order or coercion
can recover the message, either. Removing the disk and subjecting it
to STM analysis would be a waste of time.
> The reality is that what's being asked for is impossible.
Nope. It really works...
------------------------------
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 14:52:43 -0800
Joseph Ashwood wrote:
> But how do you delete my copy of the key?
You don't have a copy of the key. The plug-in guards the key context and
retrieves the key each time you click on the message -- it is discarded
and scrubbed from memory as soon as the message is rendered. The
key retrieval is secured against snooping and replay.
It doesn't stop you from taking a picture of the screen, but it
DOES solve the problem of having all of the copies of the message,
whether they be on your disk or a backup tape, disappear (become
unreadable, random bits, etc.).
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC4 and salt
Date: Sun, 05 Mar 2000 22:51:57 GMT
In article <89u5e4$dki$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <89oajs$ajf$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <Pqwv4.2411$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > I have a question about implementing "salt" with RC4. Basically,
what
> > > is the standard method?
> >
> > Just append a 32-bit tag to the session key when you
encrypt/decrypt.
> > You can even use the time() function if you don't want to code
anything
> > else. As long as each session key is unique [which is possible in
this
> > case].
>
> No, that's not the standard method (I hope not, anyway!), and to me it
> sounds scary and quite possibly insecure. (See Roos' RC4 analysis.)
>
> Go read how SSL/TLS do it. Basically, they append a 32-bit unique tag
> to the master key and *hash* them to get a RC4 session key.
>
Well in Peekboo V2 I did that [with large salts]. In PB3 I just xor
the salt against the master key. Which essentially gives the same
result. I actually use random IV's [for the CBC block] and xor that
against the key. Which saves space and makes sure that the same key is
not used twice.
I was just suggesting to use time() as a low quality source of entropy
for the task at hand.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: are self-shredding files possible?
Date: Sun, 5 Mar 2000 15:02:27 -0000
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
To consider such is an excercise in faith, to practice such
is foolishness. You have no way of stopping an individual
from taking your code, and debugging it. From there it is a
simple matter to grab the key, or create an altered client
that will permanently store the keys.
Joe
"Michael Sierchio" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
>
> > But how do you delete my copy of the key?
>
> You don't have a copy of the key. The plug-in guards the
key context and
> retrieves the key each time you click on the message -- it
is discarded
> and scrubbed from memory as soon as the message is
rendered. The
> key retrieval is secured against snooping and replay.
>
> It doesn't stop you from taking a picture of the screen,
but it
> DOES solve the problem of having all of the copies of the
message,
> whether they be on your disk or a backup tape, disappear
(become
> unreadable, random bits, etc.).
------------------------------
** 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
******************************
