Cryptography-Digest Digest #785, Volume #11 Mon, 15 May 00 23:13:01 EDT
Contents:
Re: Notes on the "Vortex" block cipher ("Trevor L. Jackson, III")
Re: Unbreakable encryption. (Eric Lee Green)
Re: What is a good Encryption program?? (Steve)
Re: Notes on the "Vortex" block cipher (John Myre)
Re: Notes on the "Vortex" block cipher (David A Molnar)
Re: Permutation Polynomials ("Dann Corbit")
An internet solution ... providing tiered security. ("C. Prichard")
X509 (Pablo Yaggi)
Re: Generator for ElGamal? (lcs Mixmaster Remailer)
Re: Unbreakable encryption. ("C. Prichard")
The IDEA simply restated. ("C. Prichard")
Tiered security solution for internet messaging ... ("C. Prichard")
Re: Permutation Polynomials (Polly & Jim Steuert)
----------------------------------------------------------------------------
Date: Mon, 15 May 2000 17:09:32 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
> >
> > On Mon, 15 May 2000 13:39:08 +0200, in
> > <[EMAIL PROTECTED]>, in sci.crypt Runu Knips
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Tom St Denis wrote:
> > >> There is some science behind cryptography whether you want to
> believe
> > >> it or not.
> > >
> > >And I think his dislike of Blowfish is only instinctive. I would
> trust
> > >Blowfish, too. It only requires a little bit too much resources for
> > >some applications.
> >
> > That particular answer of mine would have been the same for any other
> > cipher. The problem is not a particular cipher, the problem is in
> > trusting something which cannot be tested to see how closely it comes
> > to doing what we want it to do.
>
> But that's true of *any* finite state machine.
Not quite. TR expressed the purpose of the cipher as if it were a positive
statement; "what we want it to do". But that expression is confusing because
what we want is a negative proposition. The purpose of a cipher is to not
leak information. Because the purpose is negative it is not testable. More
accurately, no finite sequence of tests can prove that no leaks are possible.
> So therefore trust
> nothing? I think that's a bit bitter. Realistic or not.
>
> We need to send secure digital info, this is the best we can do. If
> cipher X stops %99.999999 of all messages from being read then Iwill
> be happy with it.
But how will you know whether it stops any percentage of messages from being
read? You can _assume_ that the cipher prevents messages from being read, but
then you're dodging the question. The fundamental issue is what basis we have
for _making_ that assumption. In theory, none.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 21:16:30 GMT
[EMAIL PROTECTED] wrote:
> A while back I posted some messages describing new encryption
> algorithms that are not breakable. It used the Virtual Calc 2000
Sigh. Snake oil salesmen strike again.
The question is not whether any given algorithm is breakable. By definition,
if data can be encrypted, it can be decrypted. The question is how much effort
it will take to produce the proper decryption key. There are some good O(1)
attacks on producing encryption keys (e.g., bribe the key clerk to give you a
copy of the key!), aside from all the usual differential, known plaintext,
etc. attacks that can produce a key in less than 2^n operations (where n is
the bit size of the key) on poorly designed encryption algorithms.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Steve)
Subject: Re: What is a good Encryption program??
Date: Mon, 15 May 2000 22:58:34 GMT
On 15 May 2000 20:13:31 GMT, [EMAIL PROTECTED] (S. T. L.) wrote:
>PGP can.
So can Scramdisk-- it makes "container files" that work like
small, extra hard drives when mounted. Everything that goes in
is encrypted on the way in, everything that comes out is
decrypted on the way out, but the container itself is never
decrypted. A very secure way to store local files, and an easy
program to use.
:o)
Steve
---Support privacy and freedom of speech with---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0xBFCE18A9 expires 5/15/01
RSA key available on request
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 17:55:51 -0600
"Trevor L. Jackson, III" wrote:
>
<snip a bunch>
> The purpose of a cipher is to not
> leak information. Because the purpose is negative it is not testable. More
> accurately, no finite sequence of tests can prove that no leaks are possible.
That's too much. As a counterexample, an "ideal OTP" can be *proven*
not to leak information. (I don't think the controversy over whether
"truly random" bits are practically obtainable changes this).
One could say that there is at present a lamentable dearth of proven
results, but I don't think it is reasonable to go further and say that
provable results are impossible.
John M.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: 16 May 2000 00:19:22 GMT
John Myre <[EMAIL PROTECTED]> wrote:
> One could say that there is at present a lamentable dearth of proven
> results, but I don't think it is reasonable to go further and say that
> provable results are impossible.
Oddly enough, there seem to be some more recent schemes which are
information-theoretically secure. Maurer's web page used to have an
excellent demo of "Secret Key Agreement by Public Discussion" which really
made a complicated protocol come home. I can't find it now; they seem to
be re-working their web page.
The idea there is that there's some source of random bits in the sky.
Alice, Bob, and Eve(a passive eavesdropper, no MITM yet) all have access
to it and are receiving a stream of bits. But the channel they use to
receive bits is noisy, and so there are all these random errors in the
string. Through a series of clever manipulations, Alice and Bob can agree
on a random string which they share, but Eve has negligible clue about.
EVEN if Eve is computationally unbounded. Then the string can be used as a
OTP.
Later his group extended this to the Mallet case..I think then Alice and
Bob have to share a very short secret with which to authenticate each
other, but then they can stretch it into as many bits as they like. The
best place to look would be Stefan Wolf's thesis (if that's up on the web
yet?) or do a web search for "secret key agreement by public discussion."
The other interesting result is in the "bounded storage space model."
Aumann and Rabin at Crypto '99.
Same deal -- there's a satellite broadcasting random bits in the sky
to everyone. Alice and Bob share a very short secret which they would like
to stretch into a longer secret.
Eve is computationally unbounded. Her only limitation is that there is
some constant bound on the amount of storage she has. It can be very big,
like terabytes, just as long as it's constant.
The idea is that the satellite in the sky is considered as outputting a
big stream of random bits. The short secret Alice and Bob share is an
index into the stream; it tells them which bits to save. So they only have
to store a few bits. Eve, on the other hand, doesn't know the secret, and
so doesn't know which bits to save -- she has to store them
all. Eventually Eve runs out of space and has to either throw away
information or not save new incoming bits. Then Alice and Bob can
use some of the bits they've saved as a OTP confident that Eve knows
a negligible fraction of them.
The best part? If Eve didn't store the bits going by, she can never get
them back. That's because we have a random bit source which will only
rarely repeat the same part of the stream twice. So it doesn't matter if
Eve buys a bigger hard drive after Alice and Bob get their OTP -- the pad
is still safe.
This explanation doesn't cover how Alice and Bob decide which bits to use
of the ones they are saving, of course. Nor does it cover the question of
"what if Eve tries to store only every other bit, or the parity of a bunch
of bits, or some function of all the bits." The paper deals with those
questions...and I don't have it in front of me at the moment. It's still
worth looking at if you want to see crypto which might be practical
without computational assumptions.
The nasty bit about both of these is that they require a public source of
random bits. Your mileage may vary as to whether that's more realistic
assumption than "RSA is hard" or "DES is hard."
Thanks,
-David
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Permutation Polynomials
Date: Mon, 15 May 2000 17:42:11 -0700
Some prototypes are missing unless you add stdlib.h
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: An internet solution ... providing tiered security.
Date: Mon, 15 May 2000 23:12:36 GMT
CipherText is already a fairly good symmetric 'ASCII' cipher. Its fast =
and it has been optimized for Page-Tag encryption. It offers the =
attractive feature of constraining its output to 7 bit characters =
compatible with the default HTTP protocol. But it needs to be enhanced =
to be regarded as a good document encryption solution.
For longer ASCII documents it would be possible to first filter the =
document for characters above 7F possibly escaping them with nulls after =
altering their value to something + 0x1F. Then encrypt using =
CipherText's double pass cipher and a numeric key constraining output to =
less than 0x7F for each value.
The document is then encrypted and ready for transmission (using the =
default protocol.)
However there is fear that CipherText is not as strong as other ciphers, =
so the message is again MASKED using the A box keys that have been =
generated as random values (32 to 127) + 128. The number of box keys =
could be moderate. 1024 would be sufficient to encrypt lots of email. =
The MSG XORED with A box results in ordinate values that can be inverted =
for transmission.=20
Decryption uses the complement B box values saving processing time to =
recover the MASKED CipherText message, that can be decrypted and =
flittered for null and value combinations to recover any converted ASCII =
characters.
Something like this would occur ( Its actually simplified with regard to =
CipherText where two keys are applied where one is very complex and =
nearly impossible to describe in terms because its values are rotated as =
articulated by the key attribute or LRC checksum.):
The methods exclude all values that are less than 0x1f except wanted =
document control characters to avoid problems with the HTTP protocol.=20
Encode:
MSG ---------> ! [ ( ( ( K[i] ^ X[i] ) - 0x1f ) ^ ( A[i] - 0x1f ) ) + =
0x1f ] -----> Y=20
Decode:
Y ---------> [ ( ( ( B[i] - 0x1f) ^ ( Y[i] - 0x1f ) ) ^ ( K[i] - =
0x1f ) ) + 0x1f ] -------> MSG=20
Decryption uses BOX B, A's complement so that one step is saved, =
improving efficiency.
A product boasting default internet protocol transmission compatibility =
for all ASCII documents would need a way to update the user with sets of =
BOX keys. It could allow the users to create their own and transmit them =
via the internet via a relay server, but the scheme seems to take away =
the privacy.
A good, workable solution to this problem could open the door for some =
development with CipherText for serious document encryption beyond the =
(extremely) limited use it now has for passwords, Page-Tags, form data, =
applet content,CHAT, cookies and the like all using the default =
protocol.
Final thoughts view the mask as something that could be updated =
periodically, and used by the utility as a measure of security to =
somewhat reduce the burden on CipherText. A 1024 byte mask would =
strengthen security against all but those in possession with the =
utility's monthly mask keys which could be optionally provided as a =
monthly service.
The somewhat practical scheme gives users ultimate control over security =
with their own sophisticated keys, and an optional masking feature that =
would require additional maintenance. The solution seems like a =
work-around for those already using 8 bit transfer protocols, but it has =
potential.
Charles Prichard
www.greentv.com
------------------------------
From: Pablo Yaggi <[EMAIL PROTECTED]>
Subject: X509
Date: Mon, 15 May 2000 21:41:36 -0400
Hi,
could anyone explain me how to set up a X509 certifacte server?
is it legal ?
Thank's
Pablo
------------------------------
Date: 16 May 2000 02:20:03 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Generator for ElGamal?
> g does not have to be a generator; however it should not just be random.
> Ideally g should generate a subgroup of prime order, where the order
> is large enough to prevent a square-root attack (say 2^180 or 2^200).
Even that is not enough. "Classic" ElGamal encryption outputs g^k, m*y^k
where k is random, y is the public key, and m is the message. Chances are
m is not in the subgroup. You may be able to learn information about m if
(p-1)/q has small factors (where q is the group order).
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Tue, 16 May 2000 01:57:37 GMT
You are looking at something similar to taking 1024 chosen values and =
applying a key to alter them before using the new set of values to =
encrypt a message.
Like applying a different base, I intend to apply a new key to shuffle =
the deck each time cards are dealt.
I see an immediate use in a CipherText based message handling system =
that uses a 1024 byte mask.
Rather than distibute new masks for each message, its simply necessary =
to associate a mask key to create a somewhat unique mask.
Its like applying a new base to a number.=20
Thanks for leading me in on this.
Charles Prichard
www.greentv.com
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: The IDEA simply restated.
Date: Tue, 16 May 2000 02:33:25 GMT
However there is fear that CipherText is not as strong as other ciphers, =
so the message is again MASKED using the A box keys that have been =
generated as random values (0 to 0x60) + 0x1f. The number of box keys =
could be moderate. 1024 would be sufficient to encrypt lots of email. =
The MSG XORED with A box results in ordinate values that can be =
transmitted.
Decryption uses the same A box values to recover the MASKED CipherText =
message that can then be decrypted and filtered for null and value =
combinations to recover any converted ASCII characters.
Something like this would occur ( Its actually simplified with regard to =
CipherText where two keys are applied where one is very complex and =
nearly impossible to describe in terms because its values are rotated as =
articulated by the key attribute or LRC checksum.):
The methods exclude all values that are less than 0x1f except wanted =
document control characters to avoid problems with the HTTP protocol.=20
Encode:
MSG ---------> [ ( ( ( K[i] - 0x1f) ^ ( X[i] - 0x1f ) ) ^ ( A[i] - =
0x1f ) ) + 0x1f ] -----> Y=20
Decode:
Y ---------> [ ( ( ( Y[i] - 0x1f) ^ ( A[i] - 0x1f ) ) ^ ( K[i] - =
0x1f ) ) + 0x1f ] -------> MSG
(It might be possible to use a BOX B that is a complement of the BOX A =
to improve efficiency if it is warranted. I haven't been able to figure =
out how the compliment works when all values get 0x1f subtracted.)
Another function of the MASK is that it also creates greater diversity =
within the MSG content domain than does CipherText when using strictly =
numeric keys. It is created so that ciphered messages are guaranteed =
compatible with the default HTTP protocol.
A product boasting default internet protocol transmission compatibility =
for all ASCII documents would need a way to update the user with sets of =
BOX keys. It could allow the users to create their own and transmit them =
via the internet using a relay server, but the scheme seems to take away =
from the privacy.
A good, workable solution to this problem appears to be that a =
transmission MASK key is simply exchanged and applied to the original =
mask image to create a somewhat unique mask. ( CipherText will do a very =
nice job of it.)
Final thoughts view the mask key as something that could be made unique =
like shopping carts and the MASK used by the utility as a measure of =
security to somewhat reduce the burden on CipherText. A 1024 byte mask =
would strengthen security against all but those in possession of the key =
( I wonder ... ). Its simply practical. Glad I thought of it.
The somewhat practical scheme gives users ultimate control over security =
with their own sophisticated keys, and an optional masking feature that =
would require additional maintenance. The solution may seem like a =
work-around for those already using 8 bit transfer protocols, but it has =
potential possibly where each client has a server component that links =
immediately to other server components like POP 3 servers. All client =
transmissions to the application server are masked by the current system =
mask on file. Transmissions within the system (from server to server) =
then use the same current mask, and when a message is delivered to the =
destination server, the mask time and mask used are noted so that the =
client application can associate the correct transmission mask with each =
message. Messages are downloaded with the set of masks and all =
decryption is then done by the client. Its more a message handling =
system than it is a client email utility, and could possibly command =
actual subscriber payments for use, as it will be expensive to establish =
and maintain the system servers.
Its the type of thing an entire class of professionals ( like the FBI ) =
might use for messaging within their organization.
Using the default protocol reduces operating costs significantly and =
possibly makes the venture even practical.=20
The sending server would correlate a destination server to the message =
and negotiate a key exchange so that the destination has a record of the =
expected message and mask key before the message is even sent. When it =
arrives, the recipient's server application waits for a request from the =
human recipient to deliver received keys and messages.
Charles Prichard
www.greentv.com
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Tiered security solution for internet messaging ...
Date: Tue, 16 May 2000 01:15:10 GMT
CipherText is already a fairly good symmetric 'ASCII' cipher. Its fast =
and it has been optimized for Page-Tag encryption. It offers the =
attractive feature of constraining its output to 7 bit characters =
compatible with the default HTTP protocol. But it needs to be enhanced =
to be regarded as a good document encryption solution.
For longer ASCII documents it would be possible to first filter the =
document for characters above 7F possibly escaping them with nulls after =
altering their value to something + 0x1F. Then encrypt using =
CipherText's double pass cipher and a numeric key constraining output to =
less than 0x7F for each value.
The document is then encrypted and ready for transmission (using the =
default protocol.)
However there is fear that CipherText is not as strong as other ciphers, =
so the message is again MASKED using the A box keys that have been =
generated as random values (0 to 0x60) + 0x1f. The number of box keys =
could be moderate. 1024 would be sufficient to encrypt lots of email. =
The MSG XORED with A box results in ordinate values that can be =
transmitted.
Decryption uses the same A box values to recover the MASKED CipherText =
message that can then be decrypted and filtered for null and value =
combinations to recover any converted ASCII characters.
Something like this would occur ( Its actually simplified with regard to =
CipherText where two keys are applied where one is very complex and =
nearly impossible to describe in terms because its values are rotated as =
articulated by the key attribute or LRC checksum.):
The methods exclude all values that are less than 0x1f except wanted =
document control characters to avoid problems with the HTTP protocol.=20
Encode:
MSG ---------> [ ( ( ( K[i] - 0x1f) ^ ( X[i] - 0x1f ) ) ^ ( A[i] - =
0x1f ) ) + 0x1f ] -----> Y=20
Decode:
Y ---------> [ ( ( ( Y[i] - 0x1f) ^ ( A[i] - 0x1f ) ) ^ ( K[i] - =
0x1f ) ) + 0x1f ] -------> MSG
(It might be possible to use a BOX B that is a complement of the BOX A =
to improve efficiency if it is warranted. I haven't been able to figure =
out how the compliment works when all values get 0x1f subtracted.)
Another function of the MASK is that it also creates greater diversity =
within the MSG content domain than does CipherText when using strictly =
numeric keys. It is created so that ciphered messages are guaranteed =
compatible with the default HTTP protocol.
A product boasting default internet protocol transmission compatibility =
for all ASCII documents would need a way to update the user with sets of =
BOX keys. It could allow the users to create their own and transmit them =
via the internet using a relay server, but the scheme seems to take away =
from the privacy.
A good, workable solution to this problem could open the door for some =
development with CipherText for serious document encryption beyond the =
(extremely) limited use it now has for passwords, Page-Tags, form data, =
applet content, CHAT, cookies and the like all using the default =
protocol.
Final thoughts view the mask as something that could be updated almost =
daily, and used by the utility as a measure of security to somewhat =
reduce the burden on CipherText. A 1024 byte mask would strengthen =
security against all but those in possession with the utility's monthly =
mask keys which could be optionally provided as a monthly service.
The somewhat practical scheme gives users ultimate control over security =
with their own sophisticated keys, and an optional masking feature that =
would require additional maintenance. The solution may seem like a =
work-around for those already using 8 bit transfer protocols, but it has =
potential possibly where each client has a server component that links =
immediately to other server components like POP 3 servers. All client =
transmissions to the application server are masked by the current system =
mask on file. Transmissions within the system (from server to server) =
then use the same current mask, and when a message is delivered to the =
destination server, the mask time and mask used are noted so that the =
client application can associate the correct transmission mask with each =
message. Messages are downloaded with the set of masks and all =
decryption is then done by the client. Its more a message handling =
system than it is a client email utility, and could possibly command =
actual subscriber payments for use, as it will be expensive to establish =
and maintain the system servers.
Its the type of thing an entire class of professionals ( like the FBI ) =
might use for messaging within their organization.
Using the default protocol reduces operating costs significantly and =
possibly makes the venture even practical.
Charles Prichard
www.greentv.com
------------------------------
From: Polly & Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Permutation Polynomials
Date: Mon, 15 May 2000 23:04:13 -0400
Thanks. Dann,
Also, on further inspection, I have found a couple of type-o's in the
comments
section which will confuse readers.
On line 37, "== 0 mod m or be == m mod 2m." should be
changed to "== 0 mod m or be == x+m mod 2m."
On line 48, "mod 2m. But P(Q(x)) = m mod 2m." should be
changed to "mod 2m. But P(Q(x)) = x+m mod 2m."
-Jim Steuert
Dann Corbit wrote:
> Some prototypes are missing unless you add stdlib.h
> --
> C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> "The C-FAQ Book" ISBN 0-201-84519-9
> C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
> C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
** 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
******************************
