Cryptography-Digest Digest #968, Volume #13 Thu, 22 Mar 01 08:13:01 EST
Contents:
ECC rather than PGP ? (Anonymous)
Re: What happens when RSA keys don't use primes? (Paul Schlyter)
Re: What the Hell...Here's what my system can do at it's best... (Mok-Kong Shen)
Re: NSA in the news on CNN (Mok-Kong Shen)
Re: AES encryption speed vs decryption speed ("Brian Gladman")
Re: DEA standard S-tables beginner question. ("Yaniv Sapir")
Re: redodancy ("dexMilano")
Re: redodancy ("dexMilano")
Re: redodancy ("dexMilano")
Re: redodancy ("dexMilano")
Re: unbreakable code ("dexMilano")
Re: What happens when RSA keys don't use primes? (Paul Schlyter)
Re: What happens when RSA keys don't use primes? (Paul Schlyter)
Multiple encryption, more secure ciphers (Joe H. Acker)
Re: What happens when RSA keys don't use primes? (Lawrence Kirby)
Re: Multiple encryption, more secure ciphers (Frank Gerlach)
Re: Czech attack to PGP (Lutz Donnerhacke)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Bob Harris)
Re: Multiple encryption, more secure ciphers (Joe H. Acker)
Re: Security of Triple-DES (Jonathan Thornburg)
Re: Czech attack to PGP (Florian Weimer)
----------------------------------------------------------------------------
Date: Thu, 22 Mar 2001 09:22:01 +0100
From: Anonymous <[EMAIL PROTECTED]>
Subject: ECC rather than PGP ?
I have just downloaded Greg Ofiesh's ECC public key encryption
program (Hidden Point Conceal 3.1).
I think that it is a viable alternative to PGP at this point, and the
executable is only 120kb in size (BIG GRIN).
Any Caveats ??.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: What happens when RSA keys don't use primes?
Date: 22 Mar 2001 08:35:21 +0100
In article <99a8nc$51e$[EMAIL PROTECTED]>,
Paul Thomas <[EMAIL PROTECTED]> wrote:
>>>I understand that. I just don't understand exactly what the
>>>"vulnerability" actually is. Will the encryption/decryption
>>>systematically break? Or will it break only occasionally, for certain
>>>plaintexts or ciphertexts? Or will it work fine, but become very
>>>vulnerable to cryptanalysis? Or something else?
>
> the encryption / decryption will break, for example
>
> let p=8, let q=6
>
> therefore n = 6 * 8 = 48
> therefore z = 5 * 7 = 35
>
> let e = 11,
>
> therefore
>
> d = 16 since 11 * 16 = 176 = 1 mod 35
>
> now suppose the message is 8
>
> then encrypting you get ...
> 8^11 mod 48 = 32
>
> but decrypting you get ...
> 32^16 mod 48 = 16
>
> and 32 != 16.
So then you just test your RSA key on some data, and if it
correctly encrypts and decrypts, then you'll know p and q
are actually primes?
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: Thu, 22 Mar 2001 09:42:34 +0100
Eric Lee Green wrote:
>
[snip]
> Now, I'm not a master cracker. I'm not a master code breaker. I'm not
> a "crypto god". I'm just a poor sod working guy engineer who spends
> his days designing systems (and trying to figure out ways to break his
> own systems). If I can find 3 1/2 cracks into an "unbreakable" system
> that was largely designed by the Department of Defense within 6 months
> of encountering a computer for the first time, I seriously doubt that
> a system designed by a rank amateur is going to last any longer
> against people who are REAL experts (which, as I said, is not me --
> I'm quite painfully aware of my own limitations).
Murphey's (?) Law always applies. The tragedy is that
one so very often forgets it. Incidently, one tiny recent
reminder is a post in the group about a flaw found in PGP.
In the other extreme, one reads in newspapers that the US
is going to launch a gigantic defense (presumably and
naturally also offensive) system against cyber warfare with
an estimated cost of 50 (?) milliards.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NSA in the news on CNN
Date: Thu, 22 Mar 2001 09:42:29 +0100
JPeschel wrote:
>
> [EMAIL PROTECTED] writes, in part:
>
> >but somehow I don't think it's
> >possible to support operations by selling coffee mugs :-)
> >
>
> Ah, but you forget about the proceeds from the bake sales,
> car wash, and Friday night bingo, which are already in the
> works. Don't tell anyone, though: it's a secret!
A remark somewhat out of context: There are a number of
certain non-government organizations that need people
constantly operating at geographically dispersed locations.
So they set up businesses ranging from pizza restaurants
(very common) to banks (few), which solves simultaneously
the financial, lodging, etc. etc. problems. Wouldn't it be
wise for the government secret agencies to do the same, at
least for the purpose of reducing the budgets? Or are they
already practicing that?
M. K. Shen
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Thu, 22 Mar 2001 09:28:42 -0000
"John Worley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Brian Gladman wrote:
>
> > For high speed implementations the encryption and decryption operations
are
> > about the same in speed terms but key setup for decryption takes a lot
> > longer than for encryption.
>
> On highly parallel machines, like IA-64, the additional cost of
computing
> the decryption keys is less than computing the encryption keys. Encryption
keys
> require ~90 cycles to compute; computing the decryption keys in parallel
adds
> ~58 cycles. Computing the encryption keys is serialized on the XOR chain
(A ^= f(D),
> B ^= A, etc.), but once the subkeys are known, the inverse subkey can be
computed
> with 4 look-ups and 3 xors in parallel with the forward keying.
>
> Thus, the full key table requires 148 cycles to compute. Obviously,
this
> is implementation is targeted at applications that encrypt repeatedly for
> a given key, but the techniques can be applied to key-agile situations.
Hi John,
Thanks for pointing this out - I guess that the correct statement is that
the decryption key schedule involves a lot more work than the encryption key
schedule. If you have many hands to do the work (and can split it up
sensibly) it might not take much more elapsed time (although a 65% increase
is still significant).
While I have not spent much time optimising the decryption key schedule, its
form suggests that it will always be a lot slower on machines with little
parallelism since the encryption key schedule is very efficient in such
environments. It is hence interesting to note how very different
implementations will need to be to cope effectively with highly parallel
architectures.
My guess is that it will take quite some time for people to develop the
mindset necessary to make this transition a success. :-(
Brian Gladman
------------------------------
From: "Yaniv Sapir" <[EMAIL PROTECTED]>
Subject: Re: DEA standard S-tables beginner question.
Date: Thu, 22 Mar 2001 11:25:56 +0200
Tom, Douglas, thanx.
Douglas, I can imagine that LUTs are the easiest and maybe the fastest
method. But, I need a function for that. My implementation will be based on
hardware (at least partly), it will be programmed in assembly, and for this
purpose, LUT are too expensive for me (believe me in that).
Tom, I tried looking for "boolean decomposition", but came with nothing
worthy. I also tried looking for "bitsliced DES" and came with nothing. Is
DEA a "bitsliced DES"?
I would greatly appreciate having a refernce or a pointer on the WWW for
this subject, or even a specific book title. The data is required fast
because of time constraints. I can already implement the other elements of
DEA quite easily with the solution I have. The only missing part is these
S-tables.
Thanks,
Yaniv.
Yaniv Sapir <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi all.
>
> I'm totally new to the crypto. field. However, I'm required to implement a
> DEA (ANSI X3.92-1981) encryptor/decryptor. My question regards the S1-S8
> selection functions. According to the standard, each function takes a
6-bit
> input and gives a 4-bit output (the tables are 4 rows by 16 cols - and
there
> are eight), where bit0 and bit5 choose one of four rows and bit1-bit4
choose
> one row member.
>
> Now, is there an analytical way of extracting the tables elements (i.e.,
> instead of using look-up tables, I want to calculate the output, based on
> the 6-bit input)?
>
> TIA,
> Yaniv.
>
>
>
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Thu, 22 Mar 2001 10:43:24 +0100
This doesn't remove redodancy. It's a transcodification.
dex
"amateur" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]...
> Simple. You assign specific code to every character.
> It's easy.
>
>
> dexMilano wrote:
> >
> > Is there some simple algoritm to remove redodancy in text?
> > I tried ZIP but it's too heavy.
> >
> > Thx
> >
> > dex
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Thu, 22 Mar 2001 10:44:22 +0100
I know it's not the correct use.
In text (non random, but written) you can reach a good level a compression,
i.e. redodancy get less.
dex
"Tom St Denis" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:JX5u6.98698$[EMAIL PROTECTED]...
>
> "dexMilano" <[EMAIL PROTECTED]> wrote in message
> news:99anrr$gqib$[EMAIL PROTECTED]...
> > Is there some simple algoritm to remove redodancy in text?
> > I tried ZIP but it's too heavy.
>
> ZIP is not meant to "remove redundancy" in all texts which makes it
useless
> for specifically constructed non random data...
>
> Tom
>
>
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Thu, 22 Mar 2001 10:48:42 +0100
That's a suggestion.
I was working on a very similar algorithm but I've a problem
How to distinguish normal word from repeated word (how to code the other
occurencies)?
dex
"Fermat" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]...
> Something like this?
>
>
> n= function_countstrings()
>
> i=0
> Repeat
> [
> i=i+1
> word(i) = word_to_compare
> for j= 1 to i-1
> ( if word(j)=word_to_compare
> then function_Remove redundance (word_to_compare)
> )
> for j=i+1 to n
> (if word(j)=word_to_compare
> then function_Remove redundance (word_to_compare)
> )
> ]
> until i=n
>
>
>
> dexMilano wrote:
>
> > Is there some simple algoritm to remove redodancy in text?
> > I tried ZIP but it's too heavy.
> >
> > Thx
> >
> > dex
>
>
>
>
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Thu, 22 Mar 2001 10:51:40 +0100
I've found a soure and I tied it.
It works but on a very slow processo with few ram it is too long to execute.
i'm looking something lighter.
dex
"John Savard" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]...
> On Wed, 21 Mar 2001 18:19:57 +0100, "dexMilano"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Is there some simple algoritm to remove redodancy in text?
> >I tried ZIP but it's too heavy.
>
> Do you mean the algorithm in ZIP leaves files that are still too big,
> or that the algorithm is too complicated for you to write a program to
> do it?
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Re: unbreakable code
Date: Thu, 22 Mar 2001 10:56:16 +0100
I'm realy impressed from the discussion.
None of you has seen a "similarity" with the protection system described by
Gibson in the SF novel "Johnny Mnemonic"?
In this case the crypto system was based on some picture taken by
television.
if you remember the movie it's easy to map this system with the one
described by thi code.
dex
"Scott Fluhrer" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:99bqnl$ain$[EMAIL PROTECTED]...
>
> dexMilano <[EMAIL PROTECTED]> wrote in message
> news:99ad0o$dorm$[EMAIL PROTECTED]...
> > For the others
> > "
> > ....
> > About all Rabin's scheme buys you is that you don't have to know how
> > to build a decent random number generator. In all other respects it's
> > just a standard one-time pad.
>
> Errr, no. For one, the key (the offsets into the random stream) is
> relatively short compared to the encrypted message. In addition, it has
the
> further feature that (given that the memory assumptions about the attacker
> are valid), if the key is revealed at a later time, the attacker *still*
> can't decrypt the message.
>
> Now, personally, I don't see why the "it doesn't matter if the keys are
> latter stolen" feature is that big a deal -- I don't see what's so
difficult
> about destroying the key after using it -- but it is something that OTP
> doesn't give you.
>
>
> >
> >
> > -Ben
> >
> > ".
> > Jacob, thx for reference.
> >
> > dex
> >
> > "Jakob Jonsson" <[EMAIL PROTECTED]> ha scritto nel messaggio
> > news:997v4h$pvn$[EMAIL PROTECTED]...
> > > Search for <Rabin unbreakable> at
> > >
> > > http://groups.google.com/groups?hl=sv&lr=&safe=off&group=sci.crypt
> > >
> > > Jakob
> > >
> > > "dexMilano" <[EMAIL PROTECTED]> skrev i meddelandet
> > > news:997s3u$3hpv$[EMAIL PROTECTED]...
> > > > I'm looking some info on this algorithm.
> > > >
> > > > http://www.securitywatch.com/newsforward/default.asp?AID=5955
> > > >
> > > > any help will be welcome
> > > >
> > > > thx
> > > >
> > > > dex
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: What happens when RSA keys don't use primes?
Date: 22 Mar 2001 10:04:26 +0100
In article <Fu7u6.25450$[EMAIL PROTECTED]>,
Mxsmanic <[EMAIL PROTECTED]> wrote:
>"Paul Thomas" <[EMAIL PROTECTED]> wrote in message
>news:99a8u6$51k$[EMAIL PROTECTED]...
>
>> dooh, my first post to sci.crypt and i fecked it up ;-)
>>
>> last line should read
>>
>> 8 != 16
>
>Not to worry; last time I checked 32 != 16, too.
In modulo-16 arithmetic these numbers are the same though... :-)
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: What happens when RSA keys don't use primes?
Date: 22 Mar 2001 10:05:03 +0100
In article <Wwcu6.100964$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> "Mxsmanic" <[EMAIL PROTECTED]> wrote in message
> news:bv7u6.25457$[EMAIL PROTECTED]...
>> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
>> news:3u6u6.98761$[EMAIL PROTECTED]...
>>
>>> No it means you should use a mathematically sound
>>> probable prime generator such that the probability
>>> of failure is astronomically small. (i.e Rabin-Miller)
>>
>> And if it fails, how will you know?
>
> You just will... who cares if the probability of failure
> is 2^-107 will you ever see a failure?
If you intend that RSA key to ever be used by anyone, why not test it
before you deliver it? Even if the probability of failure of the
Rabin-Miller generator is as small as 2E-107, there are other
possible failures with a much higher probability -- e.g. program bugs.
(btw I would call 2E-107 "astronomically small" since astronomy don't
deal with numbers as large as 2E+107. The entire known universe
contains "only" some 1E+80 atoms, for instance....)
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Multiple encryption, more secure ciphers
Date: Thu, 22 Mar 2001 11:34:21 +0100
1st question:
I've read numerous times on this group that there are enough secure
ciphers that are relatively slow. Often, many-round Feistel ciphers are
mentioned. But I haven't seen any references to specific descriptions of
such ciphers. Is there any specific 64 or 128 round Feistel cipher that
has been cryptanalised?
2nd question:
Rijndael is much too fast for my purposes. So I could use triple or
5-times encryption or even more. I've read about the caveeats of
multiple encryption modes in Schneier's AC. What I didn't understand or
missed is why one would use a scheme like EDE at all...why not EEE?
And in general: What would you do to create a stronger encryption when
you have Rijndael and the final chained cipher can be around 10 times
slower, and you may only use *one* key (but have a hash function)?
Between cipher rounds, should I XOR the key with ciphertext, then hash,
or just hash, or encrypt it or decrypt it, etc. Any ideas or references?
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (Lawrence Kirby)
Subject: Re: What happens when RSA keys don't use primes?
Date: Thu, 22 Mar 2001 00:31:46 GMT
Reply-To: [EMAIL PROTECTED]
In article <au7u6.35406$[EMAIL PROTECTED]>
[EMAIL PROTECTED] "Mxsmanic" writes:
>"Paul Thomas" <[EMAIL PROTECTED]> wrote in message
>news:99a8nc$51e$[EMAIL PROTECTED]...
>
>> the encryption / decryption will break, for example
>
>Will it break for _every_ encryption and decryption, or only for certain
>plaintexts or ciphertexts?
If it broke for every encryption and decryption wouldn't that form the
basis for a trivial primality test?
--
=========================================
Lawrence Kirby | [EMAIL PROTECTED]
Wilts, England | [EMAIL PROTECTED]
=========================================
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Multiple encryption, more secure ciphers
Date: Thu, 22 Mar 2001 13:15:36 +0100
"Joe H. Acker" wrote:
>
> 2nd question:
>
> Rijndael is much too fast for my purposes. So I could use triple or
> 5-times encryption or even more. I've read about the caveeats of
> multiple encryption modes in Schneier's AC. What I didn't understand or
> missed is why one would use a scheme like EDE at all...why not EEE?
EDE with the same key for all three steps equals to E. E.g. 3DES EDE
hardware
can thereby made compatible with plain DES.
>
> And in general: What would you do to create a stronger encryption when
> you have Rijndael and the final chained cipher can be around 10 times
> slower, and you may only use *one* key (but have a hash function)?
> Between cipher rounds, should I XOR the key with ciphertext, then hash,
> or just hash, or encrypt it or decrypt it, etc. Any ideas or references?
Always use independent subkeys for every algorithm in the encryption
pipeline.
A subkey which is functionally dependent on another subkey might create
problems, if
one of the algorithms or the subkey derivation function (e.g. MD5) is
compromised.
Using different algorithm types (eg. 3DES, RC4, Blowfish) in a pipeline
seems to be a quite
strong concept, as long as each algorithm has a fully independent key.
Never ever make the keys functionally dependent (which icludes the
trivial dependency f(k1)=k2 with k1=k2).
>
> Regards,
>
> Erich
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Crossposted-To: de.comp.security.misc
Subject: Re: Czech attack to PGP
Date: 22 Mar 2001 12:22:34 GMT
* Florian Weimer wrote:
>They seem to, see http://www.i.cz/pdf/pgp/OpenPGP_attack_CZ.pdf. It's
Great work.
>informative even if you cannot read Czech (there's one diagram showing
>the secret key packet modification, which is quite instructive). Was
Yes, it is.
>The attack is rather obvious, I have to say.
Of course, every good idea is obvious afterwards.
>I'm still working on a fix.
Assuming a bellcore attack I suggested to check it against the public key,
but there is a problem: If the major modulus of the public key is shrinked
and access to the files is assumed, there is no real reason to modify the
public key accordingly in order to fool even all the certificate checks on
my own keys. So this solution does not work.
For RSA we can fix it by regenerating the public part from the encrypted
private ones and stop working if this check failes. Afterwards we should
check the signature by the verified public key. I'll do so for PGP2.6.3(i)n.
>The basic question is: Is it possible to create a set of public DSA
>parameters which are consistent with the secret one, without knowing the
>latter?
We could check if y = g**x mod p. If p and g are not trivial (check this!)
and x is assumed to be not published before this signing attempt, there
might be a chance to prevent a format modification.
OTOH, we do not relay on a modifiction anyway, the programms are free to
choose any secret key storage format the like.
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Date: Thu, 22 Mar 2001 07:22:18 -0500
I posted:
> The idea is to have a code that includes two redundant bits, and be able to
> 'correct' any two errors, with the additional knowledge of which two bits
> might be errant. ...
My description wasn't as clear as I'd hoped (and I can see why). The
receiver will know via some other means which two bits are missing, and
needs only to fill in the missing bits.
So, for example, I might have a 5 bits message, add two bits to it
(according to my yet-undefined code), and transmit the 7 bits through
separate channels. Think of the channels as couriers. Five couriers make
it to the receiver, two never show up. The receiver knows which courier is
which, knows which haven't shown up (maybe they will, but why wait once we
have five), and then (I hope) can fill in the bits that the two missing
couriers would have.
Of the replies (and thank you all for your replies), I think the ones
related to erasures are the closest to what I'm after (probably right on).
>From the terminology in those replies, I think my problem ammounts to simply
correcting two erasures, which are detected by means outside my code.
I'm encouraged by Brian McKeever's statements:
> ... if s is the number of erasures, then we have d >= 2t+s+1.
>
> ... what you are trying is possible in theory (that is, at least a brute force
> search over all possible codewords will work), and maybe you've got enough to
> go on now?
Yes, I think I've got enough to go on now. Any further help still will be
appreciately accepted, of course. ;) But I've got a path now!
Thanks!
Bob
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Multiple encryption, more secure ciphers
Date: Thu, 22 Mar 2001 13:33:25 +0100
Frank Gerlach <[EMAIL PROTECTED]> wrote:
> "Joe H. Acker" wrote:
> > And in general: What would you do to create a stronger encryption when
> > you have Rijndael and the final chained cipher can be around 10 times
> > slower, and you may only use *one* key (but have a hash function)?
> > Between cipher rounds, should I XOR the key with ciphertext, then hash,
> > or just hash, or encrypt it or decrypt it, etc. Any ideas or references?
> Always use independent subkeys for every algorithm in the encryption
> pipeline.
> A subkey which is functionally dependent on another subkey might create
> problems, if
> one of the algorithms or the subkey derivation function (e.g. MD5) is
> compromised.
>
> Using different algorithm types (eg. 3DES, RC4, Blowfish) in a pipeline
> seems to be a quite
> strong concept, as long as each algorithm has a fully independent key.
> Never ever make the keys functionally dependent (which icludes the
> trivial dependency f(k1)=k2 with k1=k2).
Thanks for your reply. But actually, I was asking how to make one
algorithm, namely Rijndael, more secure using one key. I know that
different algorithms and different keys would be the recommended way,
but I don't have enough entropy for independent subkeys, and I can't use
different algorithms in this case.
My assumption is that the subkey derivation is the most important factor
in such a single-cipher multiple encryption, so I'm looking for a better
way to derive subkeys than just hashing them. Any ideas?
How about k2 = hash(xor(k1, ct_i)) where ct_i is the last ciphertext
block of the previous round...?
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Security of Triple-DES
Date: 22 Mar 2001 13:47:38 +0100
"Arne Baltin" <[EMAIL PROTECTED]> asked
> once more: how secure is the Triple-DES?
> I think an attack against (single-)DES with
> known plaintext of length 2^43 in 1994 succeeded.
> Is there an analogy to Triple-DES?
In article <u4A2tTmsAHA.199@cpmsnbbsa09>,
Joseph Ashwood <[EMAIL PROTECTED]> answered
| Any attack on DES can be used on triple-DES, the only problem is that none
| of them are of any use, generally they would require knowledge of more
| unique outputs than the entire codebook. As of right now the best attacks on
| 3DES hover at around 2^90 work, which is far outside the realm of possible
| success.
For further details, here are 2 references on 3DES attacks (which
contain the results Joseph Ashwood referred to):
Stefan Lucks,
"Attacking Triple Encryption,"
Fast Software Encryption '98, Volume 1372 of Lecture Notes in
Computer Science (S. Vaudenay, ed.), Springer-Verlag, 1998.
http://th.informatik.uni-mannheim.de/m/lucks/papers.html
H. Handschuh, B. Preneel, On the security of double and 2-key
triple modes of operation. L. Knudsen (Ed) 6th FSE, LNCS 1636.
Springer-Verlag, 1999.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Only 6 countries have the death penalty for children. Which are they?
A: Congo, Iran, Nigeria, (Pakistan[*]), Saudi Arabia, United States, Yemen
[*] Pakistan reportedly ended it in July 2000. -- Amnesty International
http://www.web.amnesty.org/ai.nsf/index/AMR511392000
------------------------------
From: Florian Weimer <[EMAIL PROTECTED]>
Subject: Re: Czech attack to PGP
Date: 22 Mar 2001 13:50:37 +0100
[EMAIL PROTECTED] (Lutz Donnerhacke) writes:
> For RSA we can fix it by regenerating the public part from the encrypted
> private ones and stop working if this check failes. Afterwards we should
> check the signature by the verified public key. I'll do so for PGP2.6.3(i)n.
For RSA, it's possible to compute the signature without relying on
unprotected data (that's the natural way of operation if you use the
Chinese remainder theorem to speed up computation). (The patch for
GnuPG published earlier will add additional checks that make other
attacks against the secret key less feasible as well, but even the
original GnuPG is not vulnerable to the described attack.)
I agree that it's a good idea to check the verify after computing it.
Even if it adds a significant overhead, it protects against bugs in
the MPI implementation as well (which unfortunately do occur in
practice).
> >The basic question is: Is it possible to create a set of public DSA
> >parameters which are consistent with the secret one, without knowing the
> >latter?
>
> We could check if y = g**x mod p. If p and g are not trivial (check this!)
> and x is assumed to be not published before this signing attempt, there
> might be a chance to prevent a format modification.
GnuPG already checks y = g**x mod p. However, I'm not sure if this is
sufficient, as the other parameters are not examined.
--
Florian Weimer [EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
