Cryptography-Digest Digest #45, Volume #13 Mon, 30 Oct 00 10:13:01 EST
Contents:
Re: Hardware RNGs (Tom St Denis)
Re: XOR based key exchange protocol - flawed? (Tom St Denis)
Re: Algorithm/code to encrypt to readable text (Rob Warnock)
Re: Algorithm/code to encrypt to readable text (Janne Tuukkanen)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Q. to Ritter /PKCS cascade/Hybrid PKCS ([EMAIL PROTECTED])
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: .java.policy (i figured it out) ("William A. McKee")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Mon, 30 Oct 2000 13:13:47 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> [ on randomness from soundcards ]
>
> > I wouldn't trust it either way. It's not meant to be a RNG....
>
> Agreed - using any hardware not designed for the purpose directly as a
> cryptographic RNG would be very unwise. Instead, discard *no* bits
but
> use the raw data (and raw data from wherever else you can snarf it;
> Pentium TSC or whatever) as input to Yarrow
>
> http://www.counterpane.com/yarrow.html
>
> then get your random bits from there. If you can make a half-decent
> estimate of the entropy, you're away.
You're assuming the stuff you feed Yarrow is random. Yarrow is a
perfectly predictable PRNG otherwise :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Mon, 30 Oct 2000 13:15:17 GMT
In article <[EMAIL PROTECTED]>,
Mike Connell <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> > In article <[EMAIL PROTECTED]>,
> > Mike Connell <[EMAIL PROTECTED]> wrote:
> > >
> > > Pa, Pb are RSA public keys. (X)Pi means data X encrypted under
key Pi.
> > > Xa, Xb are random blocks of data of the same size as the public
keys.
> > >
> > > 1. a -> b : Pa
> >
> > Attacker sends fake Pa
> >
> > > 2. a <- a : Pb
> > > 3. a -> b : (Xa)Pb
> >
> > Attacker sends fake Xa
> >
> > > 4. a <- b : (Xb)Pa
>
> Call the faked Pa value Pa', and the faked Xa value Xa', that means,
> after step 4:
>
> a computes XOR of Pa Pb Xa Xb
> b computes XOR of Pa' Pb Xa' Xb
>
> so the attacker must create Pa' and Xa' so that
>
> Pa' XOR Xa' == Pa XOR Xa
>
> I dont see how this can be done when the attacker doesn't know
> Xa. Could you expand a little on this attack?
That was NOT a step in your protocal...
Also what is to stop me from faking being one side of the
conversation? Unless a shared secret was negotiated before hand,
nothing. It's a friggin law of nature my friend.
That is why things like EKE/etc... exist.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Algorithm/code to encrypt to readable text
Date: 30 Oct 2000 13:37:07 GMT
G <[EMAIL PROTECTED]> wrote:
+---------------
| I'm trying to figure out how to do the following in VB:
| serial = 123456789
| date = 12/29/00
| ciphertext = abcdef123
| where the serial serves as a key and the date as plaintext. It's important
| that the ciphertext consist of typical letters and numbers. The only code
| I've found for VB is xor functions which generate non-standard characters...
+---------------
The easiest thing to do is to separate the "encryption" from the "encoding".
That is, instead of trying to write an encryption method "E" such that when
you construct a ciphertext C = E(P) that C consists of a certain set of
characters, use any old encryption algorithm you like (chosen for strength,
or speed, or whatever other characteristics your application requires),
and let the ciphertext be whatever binary trash it needs to be. Then pick
a *separate* encoding "Q" from binary to whatever printable character subset
you like, and let C' = Q(E(P)).
Some obvious choices for Q, depending on the exact restrictions on your
ciphertext and how efficient you need the encoding to be:
- Capital letters & digits only, but ciphertext expansion not a concern:
Use ordinary hexidecimal digits, two per byte of binary.
- Advantage: dirt simple
- Disadvantage: 2:1 expansion of encoded ciphertext [4 bytes -> 8 chars]
- Upper- & lower-case letters & digits *and* at least 3 other characters,
and a 3:2 expansion is acceptable: Use standard RFC 1521 (MIME)
"Content-transfer-encoding: base64", if "+", "/", and "=" are acceptable,
else modify the MIME method to use whichever 3 other characters are o.k.
- Advantage: Well-known and extremely-widely-used standard for sending
binary data in email.
- Disadvantage: Requires at least three non-letter/non-digit characters
- Disadvantage: 3:2 expansion of encoded ciphertext [4 bytes -> 6 chars]
- You have exactly "n" acceptable characters, and you want the encoding
to be as efficient as possible (minimal ciphertext expansion):
Treat the entire ciphertext as a single binary number, and print it
base "n". For example, "a-z" and "0-9" gives you base-36, which
in 7 characters lets you encode up to 36 bits. Or if you use both
upper- & lower-case letters and digits you get base-62, which in
only 6 characters lets you encode up to 35 bits.
- Advantage: Absolutely minimal expansion of encoded ciphertext
- Disadvantage: Encoding/decoding is more complex than MIME's base-64.
-Rob
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
From: Janne Tuukkanen <[EMAIL PROTECTED]>
Subject: Re: Algorithm/code to encrypt to readable text
Date: Mon, 30 Oct 2000 15:28:58 +0200
G wrote:
> where the serial serves as a key and the date as plaintext. It's important
> that the ciphertext consist of typical letters and numbers. The only code
Simplest way is represent each text byte as hexadecimal value
(two characters [0-9|A-F]). That doubles the length of scrambled
text (simple xorring is hardly an encryption method), but maybe
it isn't an issue.
Something like this (no error checking):
Public Function str2hex(plStr As String)
Dim l As Integer
Dim i As Integer
Dim retStr As String
l = Len(plStr)
retStr = ""
For i = 1 To l
retStr = retStr + Hex(Asc(Mid(plStr, i, 1)))
Next i
str2hex = retStr
End Function
Public Function hex2dec(hexStr As String)
Dim l As Integer
Dim i As Integer
Dim retStr As String
l = Len(hexStr)
retStr = ""
For i = 1 To l Step 2
retStr = retStr + Chr("&h" + Mid(hexStr, i, 2))
Next i
hex2dec = retStr
End Function
--
Fools ignore complexity
Janne Tuukkanen Pragmatists suffer it
[EMAIL PROTECTED] Some can avoid it
Geniuses remove it - A.J.Perlis
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 30 Oct 2000 15:18:36 +0100
Tom St Denis <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>,
> Mike Connell <[EMAIL PROTECTED]> wrote:
> > Tom St Denis <[EMAIL PROTECTED]> writes:
> >
> > > In article <[EMAIL PROTECTED]>,
> > > Mike Connell <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pa, Pb are RSA public keys. (X)Pi means data X encrypted under
> key Pi.
> > > > Xa, Xb are random blocks of data of the same size as the public
> keys.
> > > >
> > > > 1. a -> b : Pa
> > >
> > > Attacker sends fake Pa
> > >
> > > > 2. a <- a : Pb
> > > > 3. a -> b : (Xa)Pb
> > >
> > > Attacker sends fake Xa
> > >
> > > > 4. a <- b : (Xb)Pa
> >
> > Call the faked Pa value Pa', and the faked Xa value Xa', that means,
> > after step 4:
> >
> > a computes XOR of Pa Pb Xa Xb
> > b computes XOR of Pa' Pb Xa' Xb
> >
> > so the attacker must create Pa' and Xa' so that
> >
> > Pa' XOR Xa' == Pa XOR Xa
> >
> > I dont see how this can be done when the attacker doesn't know
> > Xa. Could you expand a little on this attack?
>
> That was NOT a step in your protocal...
>
Erm,... this is what I first wrote:
#1. a -> b : Pa
#2. a <- a : Pb
#3. a -> b : (Xa)Pb
#4. a <- b : (Xb)Pa
#
#Then a and b compute the XOR of Pa,Pb,Xa,Xb. This gives them a
#substantional number of shared secret bytes to construct a session
#key from.
I guess that it's technically not a step in the protocol itself, as it
is the result of the protocol. It is however, the entire point of
doing the protocol ;)
> Also what is to stop me from faking being one side of the
> conversation? Unless a shared secret was negotiated before hand,
> nothing.
Isn't that what you just did? The reason I dont think it will work is
that both parties have keybits, and the attacker can only get them
from one party. However, if you can point out where the flaw lies, I'd
be greatful ;)
> It's a friggin law of nature my friend.
> That is why things like EKE/etc... exist.
>
Otway-Rees? [Modified] Needham-Schroeder?
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 30 Oct 2000 14:01:46 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<x8aL5.3966$zO3.120805@stones>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Brian Gladman) wrote in
>> <eN0L5.3659$zO3.111060@stones>:
>>
>>
>> >
>> >But in arithmetic coding the original file length does need to be
>> >encoded in some way and Matt has a neat way of doing this (and one
>> >which I like). But his scheme is just one of many possible ways of
>> >encoding
>>
>> I think you don't know what he did since a length field is not
>> use in Matts arithmetic coding.
>
>I did not say there was a length field - I just said that length is
>encoded and I do know how he does this.
>
The legth is not added to the file. Zero information is added to
Mastts compressest files.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 30 Oct 2000 14:26:41 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Q. to Ritter /PKCS cascade/Hybrid PKCS
Date: Mon, 30 Oct 2000 14:33:14 GMT
I have asked you this question before, and we have discussed it very
briefly. If we extrapolate your technique of cascading symmetric block
ciphers to PK cryptosystems, the major problem here is that the end user
will have to keep multiple PKs for each sender.
I remember you said it is computers and not users which store and
remember PKs, however this does amplify the key distribution problem.
Imagine for each user you have to create 2-3 pairs of PKs.
My second question is , is it possible to create a hybrid PK
cryptosystem rather then a cascasde of PK crypto systems.
As there are three families of PK systems:
Discrete Logarithm (DL) systems
Elliptic Curve Discrete Logarithm (EC) systems
Integer Factorization (IF) systems
Is it possible to produce a hybrid from each family?
e.g. for IF RSA and Rabin-Williams
DL ->> Diffie-Hellman and MQV
or Abdalla- Bellare- Rogaway DHAES
It may be interesring for you to write a paper on this subject?
TIA
Steve
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 30 Oct 2000 14:47:04 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>Here I am in difficulty in understanding the specifics, but I think I
>may be more in agreement with Mr. Tyler here. In fact, this is
>precisely the point on which I've found Mr. Scott's bijective scheme
>flawed when he converts a compressed file to one with a length that is
>an integer number of octets.
What you fail to understand is that it is not a flaw.
and other other ture bijective way would only exist as a transform
from one to the other. The ways are there are more than one
that Matt and I have used are truley bijective for real world
8bit byte files.
>
>A file indeed has length as one of its properties. If you add bits to
>a file which encode its length, and then encrypt the result, you
>haven't added _information_ to the file, but precisely because you
That is where your logic is wrong. If your add bits to a file you
do add information to a file that can be exploited.
>have added bits containing *duplicate* information, you have added
>redundancy. (I'm sure you know this, though, and the dialogue doesn't
>really mean what it sounds like.)
>
>Thus, I've noted that the standard technique of including length
>information in a file before encryption would be, where compression
>produces a file with an arbitrary length in bits, but the file is to
>be, for whatever reason, padded out to whole bytes before encryption
>(presumably for convenience in programming) is: add _exactly three_
>bits to the file, to give only the information of the file's length
>modulo 8, and then _destroy_ the other "copy" of that information by
>padding the file with random bits.
The fact is this is not needed the end of the file is determince
when you try to get more data the operating system says sorry you
are the end. But for the N bytes the system lets you take as a file
can be what ever your devise heart wants. THere are no real restrictions
>
>From his descriptions of his scheme - despite his pleas, I have not
>considered it worthwhile to delve into his C code - it appeared to me
>that what he was proposing for "Bijective Huffman" was equivalent to
>the standard hash function technique of padding with 1000...000. Which
>does create a unique encoding, but which is biased (given the
We have killed this dead horse several times. I never used a system
that only adds bits to all files. Any system which only adds bits can
not be bijective. For the same reason you tried to prove such ends
as mine where impossible. You have to have cases where bits are sometimes
added and sometimes subtract from the data steam. Then if you can't
look at my code look at matts. He seems to be up on modern coding
techniques. But My feeling is you can't or wont look at his either, You
already seem to have a closed mind on the topic and may be many years
off before you can see the concept for what it is.
>assumption one is dealing with 'typical length' messages, not such
>short ones that the probability of a message of length N goes up with
>the number of messages of length N, that is, doubling for each
>additional bit of length).
>
>Adding _random_ bits to a file doesn't create redundancy. But Mr.
>Scott still objects to it. And legitimately! Any encryption method
>that involves the use of random bits creates a perfect hiding place
>for a subliminal channel - a maliciously altered encryption program
>can just encrypt key information, and send that as random bits, from
>which anything well encrypted to a binary output is indistinguishable.
>
Yes that is why I like to get the best before the can of worms and
god of "random" is opened as a cureall.
>This is why, in the area of my web site entitled "Red Thread
>Resistance", I give particular attention to a scheme which, it turns
>out, appears to be covered by an IBM patent, with Mihir Bellare as the
>inventor (and which I heard about in a thread entitled "Double
>Encryption Patented!"). The IV, and the session key, instead of being
>chosen randomly, can be produced based on a hash of the message, using
>an unkeyed Feistel principle; I'll give a very specific example,
>assuming a hash function producing a 128-bit hash and a cipher with a
>64-bit block size and a 64-bit key:
>
>step 1: divide message into "first 128 bits" and "rest of message".
>
>step 2: XOR first 128 bits with hash of rest of message.
>
>step 3: using first 64 bits as session key, second 64 bits as IV,
>encrypt rest of message.
>
>step 4: encrypt first 128 bits (one _could_ get away with doing just
>the first 64 bits, depending on the mode used) using key exchange key.
>
John having a file map to a unique encoding itsrlf does not prove
information was added. The process as to occure in 2 directions.
Every binary file also has to have a unique decoding in the other
direction. What 99% of people miss is that once they finally wreck
there brians to come up with a scheme that encodes uniquely in the
encrypting direction no attension is paid to see if it is unique
in the other direction. In fact many argue that it can't be done.
But there wrong as Matts code so clear shows.
>This can be _validated_ the same way that a chip can be validated to
>perform DES. No opportunity is given for any steps to be
>nondeterministic, no wiggle room exists for information to be leaked.
>Each ciphertext message is a unique function of the plaintext message
>and the key
That is not the same as what Matt Tim and me refer to as 1-1 or
bijective or as I call unadulterated.
.
>
>But "probabilistic encryption" _does_ have its virtues. How does one
>avoid problems with identical messages? The one trusted source of
>randomness, the user himself, can always type some garbage characters
>at the end of his message! If the encryption program tried to
>recognize these and alter them, it could be detected, and that would
>be difficult in any case.
>
>On another point: while compression before encryption shouldn't be
>restricted to plaintexts that are an integer number of bytes in length
>- that is a restrictive assumption, although more so if applied to the
>output of the compressor - if one knows the files will be, after
>encryption, handled in a way that requires them to be in whole bytes,
>_something_ has to be done about that.
Give me a break when is the last time you used a file of any type
that was not a whole number of bytes. The whole problem of compression
and encrption is in some wasy the results of modern computers being
8-bit byte orientated. If files where only meassured in terms of a
bit stream then thaing would be different.
I think 8bit files units as a basic thing are here to stay for
a long time. But if they change in five years it will only be to
a long base. like 16 or 64 bit units as the smallest basic unit
but Matts code is bult for real world files of today.
>
>Of course, one can always handle the message as an arbitrary string of
>bits, encrypt it that way, and then add unencrypted length information
>as part of the armoring process. That is the *proper* way to go about
>it, and if _that_ is what you are advocating, I quite agree.
If I want to play this kind of game. one could. However it saves
file space to not do this. Beause if one took one of matts output
files. You could add length to it by adding the above information. But why
all you get is a longer file. You suggest adding more information
that is not needed. However if you want to add the extra information
as some sort of consistancey check for some specail application
then fine. However if the file is sent through a net work this added
info should be protected for tampering itself. Such as do a crypto
hash adding it and reencrypting the whole file again. BUt the
central core at the heart of all the wrapping is a bijectively
compressed and bijectively encrypted data. But if you send the
same dat to several people you can even add random data to front
like the way I have suggest before and then use Matts program.
I am not saying Matt code is the end all. I am saying it is a
damn good tool that could be the heart of any crypto system and
its amsasing others have not had this kind of matching of compression
to block ciphers years ago.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.programmer
Subject: Re: .java.policy (i figured it out)
Date: Mon, 30 Oct 2000 15:08:28 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> In two places, William A. McKee <[EMAIL PROTECTED]> wrote:
>
> : 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.
>
> It's not clear to me from what you have written what you're talking about.
The original post was in comp.lang.java.programmer where I was asking how to
use .java.policy to stop unsigned .jar files from being run. Nobody knew.
It turns out you cannot do it.
>
> Java's security model is not designed to prevent unsigned jar files from
> running in the sandbox - if an attacker can place himself upstream of the
> client (excepting SSL'd communications).
>
> Nor is it clear which security exceptions you're talking about.
> These are ones that a MITM can gain access to?
I use java.security.AccessControlException to conditionally test before
running those functions that require added permissions.
>
> : 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.
>
> When do you anticipate such files being sent over the network?
If you want to setup a client machine for a user remotely you would have to
transmit this data over a network.
public.keystore holds the certificate. At the very least you would have to
send the certificate over the network.
What I do is have a SFX that does the configuration required to setup the
client machine. This must be downloaded over the network and run on the
client machine. Most people would not even know how to use the java tools
to modify .java.policy and .keystore IMHO.
I guess the best way around this security hole is to use SSL to transfer the
data.
>
> You might also like to try this in comp.lang.java.security, BTW.
Thanks.
> --
> __________ http://alife.co.uk/ http://mandala.co.uk/
> |im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
"I have seen things I cannot deny." - Scully
------------------------------
** 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
******************************
