Cryptography-Digest Digest #39, Volume #13 Sun, 29 Oct 00 20:13:00 EST
Contents:
Re: DATA PADDING FOR ENCRYPTION (Bryan Olson)
Re: DMCA bans fair use (Matthew Skala)
Re: Graphics and Encription (wtshaw)
Re: DMCA bans fair use (Roger Schlafly)
Re: Decrypt Me (Tom St Denis)
Re: Psuedo-random number generator (Tom St Denis)
Re: Graphics and Encription (wtshaw)
.java.policy (i figured it out) ("William A. McKee")
Re: Decrypt Me (Chris Nicholson)
Re: rc4 proprieties (Bill Unruh)
Re: BEST BIJECTIVE RIJNDAEL YET? (John Savard)
Re: rc4 proprieties (Bill Unruh)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: Sun, 29 Oct 2000 23:08:05 GMT
Tim Tyler wrote:
> Bryan Olson <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Bryan Olson wrote:
> :> : Tim Tyler wrote:
> :> :> What about the man sending short messages, for example?
> :>
> :> : "Message" yes, that's what the OTP is all about. "Messages"
> :> : sounds he doesn't really have a grasp of the requirements for
> :> : information theoretic security.
> :>
> :> Your implication that someone sending some short messages with a
block
> :> cypher has a screw loose appears to be unwaranted.
>
> : I implied nothing of the sort. [...]
>
> "Doesn't really have a grasp of the issues at hand" then.
>
> :> I suppose you are suggesting he should be using an OTP,
> :> and not bothering with a padding scheme?
>
> : No. Just don't bother with the pointless non-standard
> : padding schemes.
>
> The problems of padding scheme of appending a 1 and padding with 0s to
> the end of the block is the topic under discussion I believe.
Specifically, you suggested that known plaintext it adds,
and thus the ability to reject most individual keys (out of
2^128 of them) was some kind of security problem, and
followed with:
| It is true that some people are prepared to trust security
| based on the percieved difficulty of performing certain
| mathematical operations, rather than security based on an
| information theoretical lack of ability to determine
| whether keys are correct.
One who cannot trust computational security might reasonably
use the OTP. But presenting this as a justification for
bijective padding is nonsense. The same 128-bit key is not
going to provide ideal secrecy for realistic message
spaces.
> :> Using an OTP may require significantly more key material.
> :> Note that the redundancy you mentioned arises with messages
> :> longer than the unicity distance.
>
> : Wrong. It arises when the sum of the redundancy in
> : all the messages sent under the key exceeds the key
> : entropy.
>
> I was (rather obviously) dealing with the case of one
> key per message.
Then don't phrase it as a response to "the redundancy you
mentioned" when I was talking about multiple small messages
covering the key equivocation.
Very short messages happens frequently; for example an
encrypted telnet session often sends individual key-strokes.
Do you know someone sending very-small messages with a new
small key every time? (I suppose in some public-key
applications the session key is new each time, but the
unicity distance is zero so no message is short enough.)
[...]
> : That's where you've made your mistake - moving away from
> : the standard padding schemes solves no problem.
>
> It decreases the chance of an attacker being able to
> identify a correct message.
In realistic models of message space it's only nuisance
value.
> Perhaps you should specify what you think "the standard
> padding schemes" refers to. Does it include the zero padding
> discussed further up this thread, for example?
It could include the "1" followed by zeros, though I'm not
sure offhand of a standard using it. It includes similar
schemes such as adding n octets, 1 <= n <= 256, by repeating
the value n (or zero to represent 256).
> :> :> What about the man who forwards an encrypted message he has
> :> :> intercepted back to his HQ for decipherment?
>
> :> The attacker that intercepts his message may be unable to
> :> distinguish a correct decrypt from a random stream (without
> :> lots of work).
>
> : Huh? If he's forwarding intercepted messages, then there's
> : a small pool of possible plaintexts.
>
> Which may not be known to the attacker. He may not even
> know the cipher it is encrypted under. His task might be to
> strip off the outer layer of encryption and then pass the
> message to his supervisor to deal with the (classified)
> inner algorithm.
"Intercepted" means it came from an adversary. We're not
talking about how the user might get lucky and not be
attacked by that adversary. One has to defend against
chosen-plaintext in this case, where bijective padding is
useless at best.
>
> If he can recognise a correct decrypt by the zero padding,
> he may succeed.
> If the padding is not present, his job is impossible.
>
> :> Consequently adding up to 127 zero bits to the file might make
> :> finding a termination criteria much easier for him.
>
> : As John Myre wrote
> : Nobody with any sense cares, and you know why.
>
> It was false then, and is false now.
How about I give you message encrypted with a 128-bit key,
but with over 128 zero bits at the end of the plaintext. It
will have, as you defined the term, an "effective key space"
of just one key. The termination criteria will be trivial.
Want to try to recover the message?
> :> Redundancy is only useful to attackers if they can detect it.
> :>
> :> It's not a case of whether /I/ can imagine someone so
> :> clueless as to have such expections - it's why /you/ can't
> :> see that a perfectly intelligent and rational person could
> :> have such expectations.
>
> : And yet your examples fail.
>
> No they do not - you just fail to grasp them.
>
> : You thought small messages can't cover the unicity distance; [...]
>
> Which is true, under some circumstances.
Which you omitted from the example, and are false in the
real-world cases that occur every day.
> : [...] not so since you can send more than one.
>
> Um - not if there's one key per message.
>
> : You thought intercepted encrypted messages won't have useful
> : redundancy. Did it occur to you that the attacker could have
> : intercepted the same messages, or that the original sender is
> : a likely attacker?
>
> Did it occur to you that there might be other attackers not in this
> category?
>
> Obviously not.
Actually it did. I think we should design for the dangerous
cases, not the ones where we get lucky. Resist
adaptive-chosen-plaintext; don't bother adding nuisance value
against ciphertext-only.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Crossposted-To: talk.politics.crypto
Subject: Re: DMCA bans fair use
Date: 29 Oct 2000 09:19:58 -0800
In article <[EMAIL PROTECTED]>,
Roger Schlafly <[EMAIL PROTECTED]> wrote:
>The Copyright Office just declared that only two classes
>of works are exempted from prohibition against circumvention.
>They are:
>
> (1) Compilations consisting of lists of websites blocked by
>filtering software applications; and
!
--
Matthew Skala
[EMAIL PROTECTED] :CVECAT DELENDA EST
http://www.islandnet.com/~mskala/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Graphics and Encription
Date: Sun, 29 Oct 2000 17:25:06 -0600
In article <[EMAIL PROTECTED]>, Dido Sevilla
<[EMAIL PROTECTED]> wrote:
>
> By the way 64 gray levels is good enough for most people; i.e. a picture
> that has 64 gray levels is for most people practically indistinguishable
> from a continuous tone black and white photograph. Any more than that
> is too much and has more information than most human eyes can
> distinguish. The only reason why 8 bits (256 grays) is used universally
> in computer graphics is because most computers have a bias towards
> working with 8 bits at a time, and it's much more convenient to do so
> than to have 18 bits for an RGB triple... And hence, great
> possibilities for stego. I think the key document here is the
> Colorspace-FAQ.
I want ahead and made the 64 and 32 gray templates, and I shall not make
all the possibles. If you accept 94% as the worst simple fit and a
regular spread pattern, there are still scores of possibilities, some
better than others. Good stego would look like noise.
If my methods associated with base translation were uses, the possiblities
balloon quickly. Just with grayscale, the quantity of encryption and/or
stego options defy comprehension.
For condensing of graphics, JPEG is still better, but not that much. The
problem with JPEG might boild down to overhead in algorithms.
The bottom usable resolution depends on what you will put up with, ten
grays perhaps, but that is sure to be really bad for viewing, but should
do fine for OCR.
--
52) *Part of job is making whimsical, zippy, and vexing key sequences.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DMCA bans fair use
Date: Sun, 29 Oct 2000 16:05:56 -0800
Matthew Skala wrote:
> >The Copyright Office just declared that only two classes
> >of works are exempted from prohibition against circumvention.
> >They are:
> >
> > (1) Compilations consisting of lists of websites blocked by
> >filtering software applications; and
>
> !
Weren't you the one who got into trouble for accessing such a list
without permission, and they browbeat you into repenting and
promising never to do it again? Can I infer that your "!" is all
your consent decree allows you to say?
Offhand, it looks like you caved in too soon. Or maybe the
Copyright Office heard your pitiful story and decided that
others should not suffer the same fate.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Decrypt Me
Date: Mon, 30 Oct 2000 00:12:14 GMT
In article <[EMAIL PROTECTED]>,
Chris Nicholson <[EMAIL PROTECTED]> wrote:
> What FAQ?
> And this is not designed to be computer secure.
> it is a paper and pencil cypher, that hopefully should not be able to
be
> broken without the help of a semi powerful comptuer.
> In this algorithm, the key changes daily, and the key is used, along
> with the message it self, to modify the message in such a way, as to
> remove patterns that can be recognised. I wrote an encryption program
in
> basic in like 20 minutes last night.
> here's the code.
> The Efficiency is shit, i know. But it can be done with pencil and
> paper.
> And i believe, that without knowing the Key, which is what is used to
> modify the message, (in this case, P*G**) I dont believe the messages
> can be broken without the aid of a very good computer.
Right ok...
> CLS
> OPEN "I", 1, "MESSAGE.TXT"
> OPEN "O", 2, "CRYPTO.TXT"
> DO WHILE NOT EOF(1)
> D$ = INPUT$(1, #1)
> I$ = I$ + D$
> LOOP
> X = 1
> WHILE X <= LEN(I$) - 4
> T$ = CHR$((((ASC(MID$(I$, X, 1)) - 64) + (ASC("P") - 64)) MOD 26) +
64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 1, 1)) - 64) + (ASC(MID$(I$, X, 1)) -
64))
> MOD 26) + 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 2, 1)) - 64) + (ASC("G") - 64)) MOD 26)
+
> 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 3, 1)) - 64) + (ASC(MID$(I$, X + 2,
1)) -
> 64)) MOD 26) + 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 4, 1)) - 64) + (ASC(MID$(I$, X + 3,
1)) -
> 64)) MOD 26) + 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> X = X + 5
> WEND
> I$ = C$
> C$ = ""
> X = 1
> WHILE X <= LEN(I$) - 4
> T$ = CHR$((((ASC(MID$(I$, X, 1)) - 64) + (ASC("P") - 64)) MOD 26) +
64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 1, 1)) - 64) + (ASC(MID$(I$, X, 1)) -
64))
> MOD 26) + 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 2, 1)) - 64) + (ASC("G") - 64)) MOD 26)
+
> 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 3, 1)) - 64) + (ASC(MID$(I$, X + 2,
1)) -
> 64)) MOD 26) + 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> T$ = CHR$((((ASC(MID$(I$, X + 4, 1)) - 64) + (ASC(MID$(I$, X + 3,
1)) -
> 64)) MOD 26) + 64)
> IF T$ = "@" THEN LET T$ = "Z"
> C$ = C$ + T$
>
> X = X + 5
> WEND
> PRINT #2, C$
>
> CLOSE #1
> CLOSE #2
Looks like some convoluted vinegere cipher (sp?)... You should read the
HAC (various people have URLs for that...)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Mon, 30 Oct 2000 00:14:29 GMT
In article <[EMAIL PROTECTED]>,
Peter Maxwell <[EMAIL PROTECTED]> wrote:
>
>
> can you provide a link to a paper or page written by a respected and
well
> known member of the scientific communicty with adequite proof that
quantum
> phenomena are unpredictable ?
>
> i am currently an undergraduate student in physics and would like to
hear an
> alternate perspective on quantum phenomena, ie that it is not
unpredicatable.
Well if you can't observe something and it's unpredictable then it's
random. We can't see atoms and so on since they are too small, and
well they behave somewhat chaotic, so as it stands atomic decay is
random for now.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Graphics and Encription
Date: Sun, 29 Oct 2000 17:36:22 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Dumb queation: Are you suggesting to do steganography in
> black and white pictures but employ principally the same
> technique that others have been doing with coloured
> pictures, i.e. changing pixel values, or are there some
> different features in your proposal? Thanks.
>
> M. K. Shen
Grayscale is a lesser messy medium than real colors. It seemed like a
good area to look at. Ther particulars are really cut and dried for me
now. The essence of grayscale stego can be changing pixels in an
subvisually decernable manner, but the added information units need not be
one-to-one with pixels.
Color gives you three values per pixel to mess with, a bit more
complicated, and requires knowing that certai colors can sneak by some
people as different and not others. I suggest exploring and learning
simple methods first.
--
52) *Part of job is making whimsical, zippy, and vexing key sequences.
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.programmer
Subject: .java.policy (i figured it out)
Date: Mon, 30 Oct 2000 00:45:14 GMT
For those who were watching:
I added:
keystore "public.keystore";
grant SignedBy "wamckee" {
permission java.security.AllPermission;
};
to the C:\WINDOWS\.java.policy file and signed my .jar files (using
jarsigner) with the certificate I made (keytool -genkey ...,
keytool -selfcert ..., keytool -export ... and keytool -import) storing it
in the C:\WINDOWS\public.keystore file and now I can do anything I want on
the client machine from within my Java applet.
If the client machine is not setup correctly with the .java.policy and
public.keystore files, I get an exception in the applet that I can trap and
then display an appropriate message.
This is not foolproof against the Man In The Middle attack but its better
than nothing. I can see why news:sci.crypt complains that Java is not
secure since a substituted unsigned .jar files could be run "in the sandbox"
if an attacker hacks out the security exceptions. Now granted, an attacker
can't use "restricted" functions but they could, say, replace a password
prompt with a trojan to gather passwords.
Also there is the problem of securely getting the public.keystore file to
the client without being intercepted by the MITM. It would be possible to
substitute the intended certificate with a phony one then the attacker is
free to substitute his signed .jar files for the authentic ones.
Furthermore, the .java.policy can be hacked by the MITM to change the
permissions granted to the applet, thus, giving him complete access to the
client machine.
In conclusion, it is apparent that Sun has not completely thought through
it's security arrangements. And, the _user_ must be ever vigilant to make
sure that his machine is safe.
Cheers,
Will.
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
------------------------------
From: Chris Nicholson <[EMAIL PROTECTED]>
Subject: Re: Decrypt Me
Date: Sun, 29 Oct 2000 16:50:09 -0800
Its along the lines of that, but i dont think its susceptable to the same
anaylisis to find the key length.
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Chris Nicholson <[EMAIL PROTECTED]> wrote:
> > What FAQ?
> > And this is not designed to be computer secure.
> > it is a paper and pencil cypher, that hopefully should not be able to
> be
> > broken without the help of a semi powerful comptuer.
> > In this algorithm, the key changes daily, and the key is used, along
> > with the message it self, to modify the message in such a way, as to
> > remove patterns that can be recognised. I wrote an encryption program
> in
> > basic in like 20 minutes last night.
> > here's the code.
> > The Efficiency is shit, i know. But it can be done with pencil and
> > paper.
> > And i believe, that without knowing the Key, which is what is used to
> > modify the message, (in this case, P*G**) I dont believe the messages
> > can be broken without the aid of a very good computer.
>
> Right ok...
>
> > CLS
> > OPEN "I", 1, "MESSAGE.TXT"
> > OPEN "O", 2, "CRYPTO.TXT"
> > DO WHILE NOT EOF(1)
> > D$ = INPUT$(1, #1)
> > I$ = I$ + D$
> > LOOP
> > X = 1
> > WHILE X <= LEN(I$) - 4
> > T$ = CHR$((((ASC(MID$(I$, X, 1)) - 64) + (ASC("P") - 64)) MOD 26) +
> 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 1, 1)) - 64) + (ASC(MID$(I$, X, 1)) -
> 64))
> > MOD 26) + 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 2, 1)) - 64) + (ASC("G") - 64)) MOD 26)
> +
> > 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 3, 1)) - 64) + (ASC(MID$(I$, X + 2,
> 1)) -
> > 64)) MOD 26) + 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 4, 1)) - 64) + (ASC(MID$(I$, X + 3,
> 1)) -
> > 64)) MOD 26) + 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > X = X + 5
> > WEND
> > I$ = C$
> > C$ = ""
> > X = 1
> > WHILE X <= LEN(I$) - 4
> > T$ = CHR$((((ASC(MID$(I$, X, 1)) - 64) + (ASC("P") - 64)) MOD 26) +
> 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 1, 1)) - 64) + (ASC(MID$(I$, X, 1)) -
> 64))
> > MOD 26) + 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 2, 1)) - 64) + (ASC("G") - 64)) MOD 26)
> +
> > 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 3, 1)) - 64) + (ASC(MID$(I$, X + 2,
> 1)) -
> > 64)) MOD 26) + 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > T$ = CHR$((((ASC(MID$(I$, X + 4, 1)) - 64) + (ASC(MID$(I$, X + 3,
> 1)) -
> > 64)) MOD 26) + 64)
> > IF T$ = "@" THEN LET T$ = "Z"
> > C$ = C$ + T$
> >
> > X = X + 5
> > WEND
> > PRINT #2, C$
> >
> > CLOSE #1
> > CLOSE #2
>
> Looks like some convoluted vinegere cipher (sp?)... You should read the
> HAC (various people have URLs for that...)
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: rc4 proprieties
Date: 30 Oct 2000 00:49:46 GMT
In <8t9dfn$ln7vo$[EMAIL PROTECTED]> "dexMilano"
<[EMAIL PROTECTED]> writes:
]I want to verify if, with these changes, the algoritm can be deployed to
]public.
]I know that rc4 is RSA's properties, but with changes? also the compatible
]version?
rc4 is trademarked. The algorithm used to be a trade secret. The public
version is not a trade secret. Noone has any claims on a non secret
trade secret.
RSA Security has copyright on their own source code. As far as I know,
the publically available code ( sometimes called arc4) is not derived
from the copyrighted code.
]Any suggestion will be appreciated.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Mon, 30 Oct 2000 00:49:50 GMT
On Sun, 29 Oct 2000 13:51:21 GMT, [EMAIL PROTECTED] (David P Jablon)
wrote, in part:
>A more accurate statement is that there is a choice of multiple
>strong password methods that all achieve their goals and have
>survived years of scrutiny in the cryptographic community.
In response to a courtesy E-mail of this post, which I hadn't realized
was a post, I added some clarification.
I don't mean to suggest that the alternatives to EKE are not secure,
or that they are not practical. EKE _is_ somewhat more general,
somewhat simpler to understand, and not as dependent on the use of a
specific public-key algorithm. Thus, it is more usable in connection
with the sort of encryption method I envisage for an
encryption/armoring package.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: rc4 proprieties
Date: 30 Oct 2000 00:51:39 GMT
In <[EMAIL PROTECTED]> Dave Hazelwood
<[EMAIL PROTECTED]> writes:
>It was never copyrighted or patented as the company chose to keep
>it as a trade secret.
copyright applies to trade secrets. copyright only applies to the
explicit code, not to the algorithm (copyright is a protection of
expression not idea.)
------------------------------
** 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
******************************
