Cryptography-Digest Digest #162, Volume #10 Thu, 2 Sep 99 15:13:03 EDT
Contents:
Re: I need an algorithm!!!! (James Muir)
Re: Exponents in public key algorithms (Gaston Gloesener)
Re: Using Diffie-Hellman to encode keys (Eric Lee Green)
encryption for transmission ("Alex")
Blowfish (oscar morales ruiz)
How weak is a large non-prime diffie-hellman modulus? ("John Matzen")
Re: Schneier/Publsied Algorithms ("Richard Parker")
RC4 or IBAA or ISAAC to generate large random numbers (Gaston Gloesener)
Re: Using Diffie-Hellman to encode keys (Eric Lee Green)
Re: 512 bit number factored (Anonymous)
IDEA- safe? ("Jim Butcher")
Re: Schneier/Publsied Algorithms ("John E. Kuslich")
Re: THINK PEOPLE (Paul Koning)
Re: How Easy Can Terrorists Get Strong Encrypt? (Tim Tyler)
Re: How weak is a large non-prime diffie-hellman modulus? (Eric Lee Green)
Re: encryption for transmission (Medical Electronics Lab)
Re: 512 bit number factored (DJohn37050)
Re: Protecting license information ("John E. Kuslich")
Re: I need an algorithm!!!! (Eric Lee Green)
Re: Deniability (Anonymous)
Re: I need an algorithm!!!! (Sven Gohlke)
Re: CIA Vigenere END-TIMES (Vigenere2.jpg) [1/3] (JPeschel)
----------------------------------------------------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: Re: I need an algorithm!!!!
Date: Thu, 02 Sep 1999 15:22:52 GMT
In article <apkz3.1696$[EMAIL PROTECTED]>,
"Micha�l Chass�" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm a programmer student and I really need a strong Public/private key
> system algorithm that is unpatented and that do not use mod... Does
someone
> has a suggestion for me? In case that doesn't exist, an algorith
other than
> Diffie/Hellman or RSA should be appreciated....
>
Try Elgammal. It's unpatented and uses finite fields of prime order.
These fields are easier to work with than the ones of composite order.
-James Muir
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Gaston Gloesener <[EMAIL PROTECTED]>
Subject: Re: Exponents in public key algorithms
Date: Thu, 02 Sep 1999 15:01:01 GMT
Thank you very much, to all who answered me to this question. All these
mails gave me the missing link. I have implememted the square-and-
multiply algorithm to my C++ THugeBinary class to make ir useable for
cryptography.
So thanks again,
Gaston.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Using Diffie-Hellman to encode keys
Date: Thu, 02 Sep 1999 15:16:37 GMT
David Wagner wrote:
>
> In article <[EMAIL PROTECTED]>,
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
> > Thus if I have N be 2047bits, and 'x' and 'y' be 64 bits, then
> > there's approximately 2^65 possible values for 'k', [...]
>
> I hope you're not planning on using exponents with only 64 bits.
> Such a scheme can be cracked with 2^32 work using well-known techniques.
>
> Note also that if you use small exponents you much choose the modulus very
> carefully. See, e.g., van Oorschot and Wiener's work in this area.
>
> By the way, if you're going to use small exponents, you can use a smaller
> modulus. This will substantially improve your performance.
Thanks. Do you have any references to the van Oorschot and Weiner work? If the
Weiner stuff is on the 'net I probably have already downloaded it, but I'm
still plowing through these. It appears that the modulus has to be carefully
picked in order to turn the exponential distribution into an even distribution
over the field enforced by the modulus, thus the primality and mod properties.
It makes my head hurt thinking about it. Since I'm no mathematical genius, I'd
prefer to rely on someone else's judgement here.
Thinking about it, I see what you mean about 2^32 work with 64 bits, it may
actually be less (I'm not sure what current state-of-the-art is on this
problem, if I can come up with an attack in 2^32 work surely somebody else with
less rust and better math can do better).
-Eric
------------------------------
From: "Alex" <[EMAIL PROTECTED]>
Subject: encryption for transmission
Date: Thu, 2 Sep 1999 17:11:00 +0200
hi to everybody,
I have to encrypt a flow of data to transmit it on a satellite transponder
(DVB mode). I cannot use the DVB option for compatibility problems.
I would to address both a single user and a group of users (and I would add
a new user at the group when the transmission is start too) use different
keys for each user.
May I use PGP or SSL ?
thanks
Alex
------------------------------
From: oscar morales ruiz <[EMAIL PROTECTED]>
Subject: Blowfish
Date: Thu, 02 Sep 1999 17:19:06 +0200
Hi all,
I'm testing a new implementation for Blowfish Encryption Algorithm, and
I need test vectors to check it.
Can anybody send me test vectors with a key length of 128 bits and data
length of 64 bits for the Blowfish algorithm ?
Thanks,
Ciao.
------------------------------
From: "John Matzen" <[EMAIL PROTECTED]>
Subject: How weak is a large non-prime diffie-hellman modulus?
Date: Thu, 2 Sep 1999 10:33:00 -0500
I have a raft of questions here I hope someone can clear up for me.
For all practical purposes, does it really make sense to spend all that CPU
time to come up with a 2048-bit prime number, or just use a completely
random number? Would a 512-bit strong prime be more secure than a 2048-bit
weak prime? Would a 512-bit weak prime truly be stronger than a 2048-bit
odd non-prime? Is there really a quick attack against any non-prime modulus?
John
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Thu, 02 Sep 1999 14:51:37 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> IF he does not anwser some of his grouppies will tell the individual
> where the test vectors are. That way it appears anwsered and he has
> to say nothing and if the vectors are wrong or work with only
> specailly tuned versions of us code he can distance himself from any
> future comment since he did not supply the test vectors.
The Twofish test vectors are available from a book, a published paper,
the Counterpane web site, and the NIST AES CD. Since all four sources
have his name on them I suspect he would find it difficult to
successfully distance himself from the test vectors, assuming he were
inclined to do so. :-)
-Richard
------------------------------
From: Gaston Gloesener <[EMAIL PROTECTED]>
Subject: RC4 or IBAA or ISAAC to generate large random numbers
Date: Thu, 02 Sep 1999 16:15:27 GMT
The named random number generators (RC4, IBAA, ISAAC are beased on an
array of 32-bit (m) values and each run returns another array of the
same size than the first giving a set of random numbers (r).
What is the correct way to generate larger random numbers (>64 bits):
Two Methods can be done:
1. Handle large integers inside the algorithm, for example through a
C++ class of huge binaries. The question here is if the algorithm works
without any restrictions on large integers, or will the result no longer
be high-quality random numbers ?
2. Compute a set of results (r-array) and use consecutive 32-bit values
to fill-up the resulting random number. Thus the first result of a 128
bit random-number will be (r[0]<<96)|(r[1]<<64)|(r[2]<<32)|r[3],
combining the first 4 32-values to one 128-bit value. This would be the
way I would suggest, but is the result really satisfying all criteria
of random numbers, especially the gussian-distribution ?
Thanks,
Gaston
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Using Diffie-Hellman to encode keys
Date: Thu, 02 Sep 1999 16:21:30 GMT
DJohn37050 wrote:
> Also, it seems to me you are open to a man in the middle attack.
Am I? Here's how it works. X is generated on the server. If you want to install
the software on workstations, you generate an installation image on the server
which then is placed on a diskette and carried to the target machines, or
transmitted over via ssh or some other secure method (e.g. an SSL-enabled
browser). This install image has X on it. The target machine generates Y. They
do the Diffie-Hellman handshake to establish their DES key 'd'. Then everything
else forever afterwards is done via DES, including negotiating DES session
keys, or even negotiating a new DES master key that's not related to the known
Y value. Note that generating a seperate diskette or image for each machine to
be installed, with a pre-defined 'd' for that machine, is not feasible because
it could be thousands of machines being installed from a single image.
Hmm... let's see what kind of attacks there could be with a common X:
John Paul Ringo Shared(network) Shared(secret)
x X=g**x mod N
y Y=g**y mod N
z Z=g**z mod N
k_y=Y**x mod N
k_y=X**y mod N
k_z=Z**x mod N k_z=X**z mod N
Hmm, if a machine is compromised and X uncovered, a man-in-the-middle attack
could occur. Otherwise, Paul and Ringo won't arrive at the same 'k' as the
attacker. In addition, this is not on the public Internet so we can with some
certainty assume that the IP address for John is valid and has not been
hijacked (I run the 'arpwatch' utility and use a switched network fabric in my
network, and I assume that any network running secure traffic will have similar
characteristics), and we can encode this on the install image also. Of course,
assuming anything is ridiculous, and if { a) the attacker gets his hands on the
diskette and thus gets X, or b) the image is transmitted via an insecure
channel and the attacker gets X, or c) gets X from one of the client machines,}
and d) the network architecture allows address "spoofing" (to negate the
hardwired IP address in the image), a man-in-the-middle attack is quite
possible.
Note that I'm concerned about somebody spoofing being John. I don't care if
someone pretends to be Paul or Ringo, because while John can screw Paul and
Ringo, Paul or Ringo cannot screw John in this particular application. (Unlike
real life, grin). John always initiates the connections and tells Paul or Ringo
what to do, Paul and Ringo never initiate connections or tell John what to do.
John does recieve data from Paul and Ringo, but stashes that data aside and
otherwise does nothing with it.
Hmm. Perhaps multiple x's, generated each time an image is generated. Thus if
you do a bulk install of 500 machines off of one image with X_1 on the image,
John then initiates the DH chat with each machine to do the initial key
transfer. But there may be multiple images for multiple architectures
outstanding at any given time, so this also means that the client will need to
transmit an identifier for "which X?" as part of sending Y to John, so that
John knows which x to use for that client's key so that their values of k are
matched. This would avoid the problem of the attacker getting X off of a
machine installed last month, then using it to do a man-in-the-middle attack on
a machine installed this month (assuming a new install image was generated for
the machine installed this month).
Of course, if John is compromised, the whole game is up, since he has copies of
everybody's keys. Since this all must run unattended, we can't use SPEKE or
such to require a passphrase in addition to the stored values. I prefer not to
think about it (sigh), since a compromised John could push a new /etc/passwd
out to Paul or Ringo and really screw them :-(. Thus if I were attacking this
setup, I would attack John, not the encryption.
-- Eric Lee Green [EMAIL PROTECTED]
------------------------------
Date: Thu, 2 Sep 1999 18:37:16 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Bob Silverman <[EMAIL PROTECTED]> writes
> It has been well known since 1990 that 512 bit keys were breakable
> and within computer capabilities.
So, supposing you write a similar comment 9 years from now, how could
you fill in the blank:
It has been well known since 1999 that _____ bit keys were breakable
and within computer capabilities.
What is the largest value which you would feel comfortable putting in the
blank today, with the same level of assurance as with the 1990 statement?
In other words, what size keys appear equally as breakable today as 512
bit keys appeared in 1990?
------------------------------
From: "Jim Butcher" <[EMAIL PROTECTED]>
Subject: IDEA- safe?
Date: Thu, 2 Sep 1999 11:12:22 -0500
has anyone heard of a successful cryptanalysis of the IDEA algorithm? 128
bit key, 64 bit block size
for that matter Blowfish 256 bit key?
Jim Butcher
[EMAIL PROTECTED]
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Thu, 02 Sep 1999 10:43:56 -0700
Even if the source code is reviewed by God himself, and the code is perfect, it means
nothing to the ultimate trust one should put in the code operating
properly on your machine. Once in memory, the code is easily altered by a trojan
inserted by Back Orifice or by other surreptitious means. The PC is not
secure, ergo code running on a PC is not secure. The only secure encryption is
harware encryption.
JK
Eric Lee Green wrote:
> Mixmaster wrote:
> > How is it posible that some of your published algorithms...2fish have bugs in
>your source code?
>
> And how is it possible that some published operating systems, like
> Windows NT, have bugs in their source code?
>
> > There are only two possible explanations for this:
> > 1. A legitimate mistake was made...but no correction was ever published for
>it...or have you published the correction on your site..
>
> Bruce generally publishes corrections on his site. Unfortunately, if you
> are outside of the U.S. you cannot get to the appropriate places on his
> site, due to Washington brain damage.
>
> > How can we in the crypto community EVER Trust any Publsihed Source Code without
>extensive testing and debugging... I wonder if you thought of this.
>
> Answer: you can't. That's why it's so important that the source code to
> cryptographic algorithms (and source code to security-related software
> in general) be publically published and reviewed by a large audience of
> cryptographers and software engineers, so that flaws and errors can be
> detected. Those who talk about "security by obscurity" delude themselves
> by believing that they have "perfect" code without having had thousands
> of eyes doing a line-by-line analysis of that code looking for errors
> (especially true when you have dueling candidates for a future standard,
> you can bet that each of the major contenders is going line-by-line
> through each competitor to find some weakness).
>
> --
> Eric Lee Green http://members.tripod.com/e_l_green
> mail: [EMAIL PROTECTED]
> ^^^^^^^ Burdening Microsoft with SPAM!
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: THINK PEOPLE
Date: Thu, 02 Sep 1999 12:31:08 -0400
"SCOTT19U.ZIP_GUY" wrote:
>
> It really amazes me how little thinking gets done in this group.
Perhaps that's because of all the time we waste skipping
past your cephaloplegic ranting.
paul
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 2 Sep 1999 17:01:12 GMT
Greg <[EMAIL PROTECTED]> wrote:
: In case anyone is interested, [...]
: Indeed, a recent study [...] found good encryption programs available
: outside the United States on more than 800 Websites.
Did you read the sci.crypt charter before posting? This type of post
is explicitly mentioned as being inappropriate.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Put not your trust in money - put your money in trust.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: How weak is a large non-prime diffie-hellman modulus?
Date: Thu, 02 Sep 1999 17:31:25 GMT
John Matzen wrote:
> I have a raft of questions here I hope someone can clear up for me.
>
> For all practical purposes, does it really make sense to spend all that CPU
> time to come up with a 2048-bit prime number, or just use a completely
> random number? Would a 512-bit strong prime be more secure than a 2048-bit
> weak prime? Would a 512-bit weak prime truly be stronger than a 2048-bit
> odd non-prime? Is there really a quick attack against any non-prime modulus?
The purpose of the two primes in g**x mod N (g is a small prime, N is a large
one) is so that the results of the exponential curve g**x will be evenly
distributed over the field N. Let's do Diffie-Hellman with some small numbers:
x=[0..11] N=13 g=2
X= [1,2,4,8,3,6,12,11,9,5,10,7]
Note that: every number between 1 and 12 is represented, and no number is
represented twice.
Now, let's choose a non-prime odd N, like, say, 15:
X= [1,2,4,8,1,2,4,8,1,2,4,8,1]
Ack! Only four numbers are represented out of the entire field of 13, there is
a repeating pattern, and those four numbers are also the only values of k!
Note that you don't need to generate a new 2048-bit prime number every time.
All you need is a big enough prime number to generate a field big enough to
hold your resulting values. It appears from the example above that in order to
get an even distribution of 'x' over the entire field, it must be in the range
0..p where p is at most the prime number that's closest to N-1, but I'm still
looking for the paper on that, so don't believe me, I haven't done the math on
it yet (and don't intend to, since somebody else has already done it).
-Eric Lee Green [EMAIL PROTECTED]
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: encryption for transmission
Date: Thu, 02 Sep 1999 12:07:18 -0500
Alex wrote:
>
> hi to everybody,
> I have to encrypt a flow of data to transmit it on a satellite transponder
> (DVB mode). I cannot use the DVB option for compatibility problems.
> I would to address both a single user and a group of users (and I would add
> a new user at the group when the transmission is start too) use different
> keys for each user.
>
> May I use PGP or SSL ?
Sure, but it'll be kind of slow for a satellite
link. How much of the bandwidth is each user
using? If it's just a few per cent, PGP will
work fine (assuming you have some horsepower
to play with :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 512 bit number factored
Date: 02 Sep 1999 17:52:27 GMT
Good question.
Don Johnson
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Protecting license information
Date: Thu, 02 Sep 1999 11:07:52 -0700
Fatbrain.com announced their new e-matter program the other day. They claim to have a
copyright protection scheme on their e-matter documents so that only those who have
purchased rights to read the documents can access them.
Has anyone heard what sort of protection scheme they are using and how secure their
scheme is??
By the way, there will probably be a lot of interest in this scheme from typical
newsgroup readers. I can envision lots of netizens who have valuable info that they
would like to publish and earn royalties on.
CRAK Software will be selling a white paper on the subject of Word 8 encryption within
the next few weeks. We will detail the exact encryption / decryption process used and
reveal all the secrets needed to take a Word 8 document and and recover the ENTIRE
file.We will include the non - standard padding used for the unicode password when it
is
MD5 hashed, the details on the silly little re-keying operation done during decryption,
and the relationship between the table data and the password.
But there are two problems:
1) What is the best pricing for such information?
2) How do you keep some turkey residing in Lower Slobovia from buying the paper and
copying it to a newsgroup? Does this imply keeping the price high enough to discourage
this behavior?
Copyrights are practically impossible to enforce when residents of foreign countries
violate them. It seems that if Fatbrain.com is to be successful they must have a good
solution to the problem but details are sketchy on their web site.
Perhaps a flood of e-mail questions to this company sci.crypt fans would cause them to
reveal more detail on how they plan to proceed?
John E. Kuslich http://www.crak.com
Ranche wrote:
> I'd like to provide different versions of my application using some sort of licenses.
> I want to make sure that nobody except me can create valid licenses.
> What is the best way to achieve this?
>
> --Ranche
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: I need an algorithm!!!!
Date: Thu, 02 Sep 1999 16:49:48 GMT
"Micha�l Chass�" wrote:
> I'm a programmer student and I really need a strong Public/private key
> system algorithm that is unpatented and that do not use mod... Does someone
> has a suggestion for me? In case that doesn't exist, an algorith other than
> Diffie/Hellman or RSA should be appreciated....
Diffie/Hellman is no longer patented (it expired). All public key systems that
I'm aware of do use mod (or exp_mod). Nobody seems to have a general patent on
elliptic curve cryptography, but note that all that's happening with these
systems is that they're using a curve other than the exponential curve used in
Diffie/Hellman and they do require the mod in order to distribute the results
of the curve over a field, just as with Diffie/Hellman. ElGamal, a variant of
Diffie/Hellman, is also available patent-free, I am currently looking at it to
see if it will suit my own needs. The ciphertext is twice the size of the
plaintext, so ElGamal would only be suited for transferring the key for a
symmetric encryption algorithm, and for doing digital signatures. For a good
private key encryption algorithm, look at any of the AES candidates such as
Serpent, Twofish, etc. If it's for a commercial product to be exported, you'll
need to use a less-good algorithm, 56-bit DES.
-Eric Lee Green [EMAIL PROTECTED]
------------------------------
Date: Thu, 2 Sep 1999 18:45:58 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Deniability
DENIABLE ENCRYPTION, Canetti et al, Crypto 97, p90, available at
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/deniable_abs.html.
The proposed method for deniable public key encryption has one major flaw:
it is for the sender only. A sender can public-key encrypt a message
to someone else's key. Then if the eavesdroppers come to the sender
with the ciphertext and demand to know what plaintext was encrypted,
he can plausibly respond with any plaintext whatsoever.
This is not really very useful. Normally when public-key encryption is
used, as in PGP or S/MIME or SSL, what is encrypted is a "session key"
which will be used to encrypt the rest of the message using a symmetric
cipher like 3DES or CAST. The session key itself is padded with random
data before encryption. None of this is normally saved by the sender;
not the session key, and not the random padding. There is no reason
and no point in his saving this.
If, after sending a normal PGP encrypted public key message, an
eavesdropper came to the sender and demanded that he reveal what he
had sent, he couldn't do it. The sender didn't save the session key,
and even if he had, he wouldn't have saved the random padding that was
used in the RSA encryption. There is no way he could prove that any
given session key was actually RSA encrypted.
This means that, in practice, when public key encryption is used the
authorities must go to the message recipient, not the sender, in order
to get him to decrypt the message.
The system from Canetti et al doesn't help much in this case. What they
suggest is that if you want recipient deniability, the recipient
should first send a random string to the sender's public key, using
the sender-deniable method. Then the sender uses that random string
as a OTP to encrypt the data he wants to send to the receiver. Presto,
they claim, we have receiver-deniable public key communication.
Well, this doesn't really work. In a public key protected conversation,
if authorities are demanding decryption, they will be going to both
parties, in order to get both halves of the conversation. If they do
that, the deniable encryption won't work because one party or the other
is doing the public-key decryption, and they aren't protected by the
Canetti method.
Furthermore, if extra message transfers are acceptable, a much more
effective approach is simply to use Diffie-Hellman key exchange to get
forward secrecy. With that, neither party can decrypt messages which were
sent earlier. They don't know the keys, they can't recover the plaintext.
However, bearing in mind these limitations, here is one version of the
Canetti method. You need to be able to send one of two kinds of messages,
which they call S and R. R is just a random bit string the size of the
recipient's public key modulus, say 1024 bits. S is a 1024 bit value
which will decrypt to some recognizable form, such as a value with a
fixed pattern in the low 64 bits. It is easy to create S messages; pick
a value of the proper form and RSA encrypt it. Likewise it is trivial
to create R messages. However no one but the receiver can distinguish
S from R, which he does by RSA decrypting and seeing if the low order
64 bits hold the special pattern.
If forced to reveal what was sent, it is possible to prove that an S was
sent by remembering the value which was RSA encrypted. However, if an
S was sent it is also possible to lie and claim that it was an R, just
a randomly chosen value. You can honestly show that an S was an S; you
can lie and claim that an S was an R. You can't lie and claim that an
R was an S though.
Now, here is how this is used. You send a pair of values for each bit
you want to send (quite a bit of message expansion here! 2x1024 bits
sent just to communicate a single bit). To send a zero you send either
(R, R) or (S, S). To send a one you send (S, R). The recipient can
distinguish these, and basically sets the decrypted bit value based on
whether the number of S values is even (bit = 0) or odd (bit = 1).
If forced to reveal what was sent, deniability works as follows.
Suppose a zero was sent. Then although you could theoretically have
sent either (R, R) or (S, S), actually you always send the latter if
you want deniability. You can then claim this was (S, R) if you want
to claim you sent a 1. Now suppose a one was sent, as (S, R). If you
want to claim you sent a 0, you claim this was (R, R). Each of these
lies involves claiming an S was an R, which can't be detected.
Even though this is called "deniable" encryption, this name is somewhat
misleading. The whole system is set up so that any plaintext whatsoever
can be claimed to be valid. The result is that the system is essentially
equivalent to one where the sender can't show anything at all about what
the plaintext was. This is basically what you get already with PGP.
Overall, this method for public-key sender-deniable encryption is not very
practical or useful. Better is to use Diffie-Hellman key exchange to get
a pair of symmetric keys which will be used long term, and to use one of
those to send sensitive messages while the other sends cover traffic.
(This technique for deniable encryption with symmetric keys is described
in the Canetti paper.)
When you're not sending sensitive material, you encrypt the message with
the cover-traffic key and pad it with an equal sized block of random data.
This is your normal mode of operation. When you need deniability, you
lie and claim that this was what you used, that only half the message
can be decrypted and the other half is noise. You then decrypt the
cover half and your real message is kept safe.
------------------------------
From: [EMAIL PROTECTED] (Sven Gohlke)
Subject: Re: I need an algorithm!!!!
Date: 2 Sep 1999 10:18:25 +0200
"Michael Chasse" <[EMAIL PROTECTED]> writes:
> I'm a programmer student and I really need a strong Public/private key
>system algorithm that is unpatented and that do not use mod... Does someone
>has a suggestion for me? In case that doesn't exist, an algorith other than
>Diffie/Hellman or RSA should be appreciated....
Diffie-Hellman is free. You may use it with ElGamal. As I know Unix PGP V5
implements ElGamal (and Diffie-Hellman is in fact the same).
Sven
--
Sven Gohlke <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: CIA Vigenere END-TIMES (Vigenere2.jpg) [1/3]
Date: 02 Sep 1999 18:03:49 GMT
collomb" <[EMAIL PROTECTED]> babbles, in part:
>I am going to explain why the square Vigenere of Kryptos
>comprised 4 columns in excess on the right and an additional line on the
>bottom.
>Why?
>Those who consulted my site web�:
>http://calvaweb.calvacom.fr/collomb /
>know that the solution of the puzzle of Kryptos comprises word GOD
>written diagonally.
>Curiously there is a possibility of revealing GOD diagonally in the
>Vigenere-Kryptos square and only one.
Why do persist in spouting this nonsense?
Surely, by now, you've read the newspaper accounts about the Kryptos
sculpture.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.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
******************************
