Cryptography-Digest Digest #53, Volume #10 Sun, 15 Aug 99 18:13:03 EDT
Contents:
CBC, IV's, and Blowfish (Keith Monahan)
Re: New encryption algorithm (Mok-Kong Shen)
Re: (Game) 80-digits Factoring Challenge (Gerhard Niklasch)
Re: NIST AES FInalists are.... (Larry Kilgallen)
Re: chat sessions? ([EMAIL PROTECTED])
Re: Wrapped PCBC mode ([EMAIL PROTECTED])
Re: CBC, IV's, and Blowfish ([EMAIL PROTECTED])
Re: CRYPTO DESIGN MY VIEW ("Douglas A. Gwyn")
Re: chat sessions? (Ruud de Rooij)
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: chat sessions? (Tom St Denis)
Re: chat sessions? (Tom St Denis)
Re: Wrapped PCBC mode (Bauerda)
Re: NIST AES FInalists are.... (Tom St Denis)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Keith Monahan)
Subject: CBC, IV's, and Blowfish
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Aug 1999 18:44:25 GMT
I understand the use of an IV in CBC mode is to fill the feedback
register with something different initially so the same plaintext
won't encrypt to the same ciphertext given the same key.
I also know that every decrypt cycle requires an initial IV as input.
In the case of Blowfish, it requires 64 bits, in my case (2) 32-bit
DWORDS.
In the case that the IV is transmitted in the clear grab the 64-bits
stuff them into variables, and then grab first cipher block using that
IV along with your key to decrypt.
Is it common practice to store the IV in plaintext, or is it common
practice to encrypt the IV with the key?
If the IV is encrypted, then when you go to decrypt the stored IV, you
still need an IV as input to THAT function. My question is this. Is
that very first IV all zeros? It would have to be, since you don't
have anything else. Right?
Keith (email server is currently unavailable, please post reply and cc
email -- thanks)
P.S. For clarity's sake pseudocode follows
When IV is stored in plaintext -- This is straight forward.
IV=fread (filepointer, 64 bits)
ciphertext=fread(filepointer, 64 bits)
Decrypt(IV, keyaddress, ciphertext, ptbuffer, 8 bytes)
When IV is encrypted
IVciphertext = fread(filepointer, 64 bits)
is the next line Decrypt(<all zeros>, keyaddress, IVciphertext,
actualIV, 8 bytes) ????
ciphertext=fread(filepointer, 64 bits)
Decrypt(actualIV, keyaddress, ciphertext, ptbuffer, 8 bytes)
ptbuffer == first real data block.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New encryption algorithm
Date: Sun, 15 Aug 1999 20:25:24 +0200
JPeschel wrote:
>
> He could present it at a crypto conference or publish it in a respected
> journal first.
Unfortunately there is in fact a problem besides the acceptance
of manuscripts. As far as I know, anything published will not qualify
for a patent in Germany. I vaguely remember that this is not the case
in US, but I am not sure of that.
So the surest way to protect the priority and value of one's ideas is
to obtain patents. To take and maintain patents can cost quite a lot
of money, however, especially if the coverage is to be international.
On the other hand, I was told that, if the intention is merely to have
a proof of one's priority (proof for one's fellows in a scientific
discipline) and not to unconditionally prevent others to make
money with the same ideas, one can apply for a patent in certain
countries, e.g. Germany, where after a preliminary examination the
text of the patent application is published by the patent office in
its bulletin for public review. At this point one can discontinue
the patent process. This way, one pays only a fairly minimal sum of
money (assuming that one can formulate the application without the
help of patent lawers) but has one's ideas documented in an official
publication. As far as I know, the same can't be done in US, since
there is no public review of US patents.
M. K. Shen
======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Gerhard Niklasch)
Crossposted-To: sci.math
Subject: Re: (Game) 80-digits Factoring Challenge
Date: 15 Aug 1999 19:15:13 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
kctang <[EMAIL PROTECTED]> had written:
|> > >>> Please factorize the 80-digits number:
|> > >>> 256261430091697968103677033465028955910<continue at next line>
|> > >>> 15360341017076023809547878443033203276429
|> ...
Somebody else, I hope with tongue firmly planted in cheek, had
suggested the following `solution':
|> > >>74681239503223976540012391
|> > >>73935890729093478299508777
|> > >>10094892705484334775926633
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dik T. Winter) writes:
|> Calculators ar no longer what they used to be...
FWIW, the factors are in fact
390347485656505685796633763675565645387
and
65649565965745836645455485654584436466567
(found after only ~8 hours of CPU time using MPQS, see
<7o0bn5$au4$[EMAIL PROTECTED]>).
Which leaves us with a secondary puzzle -- how did the original
challenge arise? A little examination of the factors suggests
that they were chosen with careful attention to all the heuristics
for a `good' RSA modulus, designed to defeat the factoring attacks
based on some p+-1 having no large prime factors etc., except that
the number isn't quite large enough to be safe nowadays. (MPQS is
quite immune to those heuristics...) Now I wonder whether some
instructor teaching an introductory course in cryptographic methods
and armed with a wry sense of humor had set this as an exercise, or
whether the original poster had carefully applied everything learned
in such a course and was having a little fun challenging the rest of
the world...
(Personally, it was nice seeing the latest PARI beta snapshot cope
with this. Last year, Igor Schein and myself had spent many CPU
days chasing PARI's MPQS implementation, derived by Thomas Papanikolaou
and Xavier Roblot from LiDIA's, into the remotest corners for debugging
and tuning. Back then I had never been able to finish a factorization
of anything longer than 78 digits. My dear cow-orkers kept crashing
or rebooting their workstations too frequently! Back then, none of
these had a 333MHz UltraSPARC-II CPU ticking inside it, which made all
the difference this time...)
Enjoy, Gerhard
--
* Gerhard Niklasch <[EMAIL PROTECTED]> * spam totally unwelcome
* http://hasse.mathematik.tu-muenchen.de/~nikl/ ******* all browsers welcome
* This .signature now fits into 3 lines and 77 columns * newsreaders welcome
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: NIST AES FInalists are....
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Aug 1999 18:44:26 GMT
In article <7p2c6c$21oc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
writes:
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>>"SCOTT19U.ZIP_GUY" wrote:
>>> IF there is no secret NSA entry in the remaining contenders
>>> then we tax payers are not getting our moneys worth.
>>
>>I think it's more probable that they're ready to propose a
>>decent alternative if the AES winner turns out to not be good
>>enough for its intended use within the "national infrastructure".
>
> I think your very wrong here for two reason. They tried to
> force the Clipper chip on people and it failed. So they are
> not stupid.
Mr. Scott, your faith in government exceeds your knowledge of history.
Before they tried promoting the Clipper chip, they tried
promoting CCEP, the Commercial COMSEC Endorsement Program,
which involved commercial vendors accepting chips with secret
government algorithms.
After they tried promoting the Clipper chip, they tried
promoting Fortezza use with another secret government
algorithm.
So the fact that an approach failed for the government in
the court of public crypto opinion does not preclude another
similar attempt.
Larry Kilgallen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: chat sessions?
Date: Sun, 15 Aug 1999 19:13:30 GMT
In article <[EMAIL PROTECTED]>,
*@spam.ruud.org wrote:
> [EMAIL PROTECTED] writes:
>
> > I was thinking in order to promote more discussion why not have live
> > chat sessions for the group? We can discuss things more rapidly
then
> > thru newsgroups ...
> >
> > How about 8PM (-5:00 GMT) every sunday on EFnet in the
group 'scicrypt'.
> >
> > I will be using the server 'irc.idirect.ca' if anyone is interested.
> >
> > Everyone is invited, and there are no real topics. We will just
find
> > something to talk about. And please no flaming people or other
groups.
> >
> > It's in 6.5 hours from now hopefully one or two can show up.
Hopefully
> > next week more...
>
> For next time, could you consider a time that is somewhat more
> friendly to Europeans. Monday morning 3am is not exactly
convenient :-)
I am so sorry. How about 3PM GMT (that's 10AM my time, and 10PM your
time) for next sunday?
Can anyone make it for say 10 minutes at least tonight (1AM GMT) just
to get an idea of who can show up (or responsed to the posts here)?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Wrapped PCBC mode
Date: Sun, 15 Aug 1999 19:49:59 GMT
In article <7p6vus$37ok$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> >[EMAIL PROTECTED] wrote:
> >>
> >> Can someone name me one benefit of Dave's 'super-duper' W-PCBC
mode?
> >
> >A brute-force-attack needs slightly more time since one has to
decrypt
> >the whole message to find out whether the key produces garbage or
not.
> >The factor is
> >
> > (number of blocks) * (number of 'wraps')
> >
> >So for a message with 2^6 blocks and with 4 encryptions (4 'wraps')
> >you'll win 8 bit of strength against brute-force-attacks.
> >
>
> Actually you gain far more than that. Since all of the blessed
chaining
> modes only require a few blocks at most to be analyzed your need to
> look at fewer than a dozen such blocks. Even the NSA is not so stupid
> that it would look at a whole file for a blind seaerch of a key when a
> small easy to search segment is all that is needed. Plus if your using
> special asynchrous digital custom machines it is far easy and less
hardware
> intensive to just use a small fragment of the file. This task is much
harder
> with "wrapped PCBC".
I agree with the previous post but not this.
Your wrapped-pcbc mode does have the benefit of making keysearch
slower, but there are easier methods. It's not conceptually harder to
brute force your method then say CBC, it's just slower (which may be a
plus). However your method requires the message to be complete before
encrypting (something which is not always possible).
1. Use a slow keysetup (ala Blowfish)
2. Multiple encryptions
I still don't think your method is any good.
1. Doesn't promote integrity over say a hash of the message
2. Doesn't enhance security
3. Doesn't delay key searches
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CBC, IV's, and Blowfish
Date: Sun, 15 Aug 1999 19:53:57 GMT
<snip>
The IVs do not have to be secret, but they should be unique (starting
IV) to each message. They are essentially 'salt' values.
The reason why they don't have to be secret is (from AC) consider
encrypting your second block... The IV is just C[0].
I would use
IV = time_since_1990_in_msec
C[0] = Ek(P[0] ^ IV)
IV = C[0]
... loop as required with
C[i] = Ek(P[i] ^ C[i - 1])
IV = C[i]
...
The goal of CBC is to ensure some message integrity (avoid replay
attacks)...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Sun, 15 Aug 1999 20:01:12 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Note this does not mean that they have broken the system
> only that there is enough information to break it.
I appreciate the extended discussion along these lines.
> know that the words "Kill all the Cats" is somewhere ...
> ... Next suppose the guy is a little brighter and used
> my "adaptive huffman compression" [now] the attacker has
> no idea of what the compressed string looks like ...
That's not strictly true. He doesn't know *exactly* what
it looks like, but he should be able to determine relative
likelihoods, based on known population statistics for
plaintext. While it foils a simple known-plaintext attack,
it doesn't guarantee that a more sophisticated attack based
on statistics might not succeed.
> Something the BS crypto gods do not want you to do.
If you mean Bruce, I don't recall him ever saying you
shouldn't compress before encryption, especially if it
doesn't result in fixed headers etc. Virtually everyone
agrees that that makes certain attacks more difficult.
------------------------------
From: Ruud de Rooij <*@spam.ruud.org>
Subject: Re: chat sessions?
Date: 15 Aug 1999 21:39:08 +0200
Reply-To: *@spam.ruud.org
[EMAIL PROTECTED] writes:
> I am so sorry. How about 3PM GMT (that's 10AM my time, and 10PM your
> time) for next sunday?
3pm GMT is actually 5pm my time. Sounds OK.
- Ruud de Rooij.
--
ruud de rooij | *@spam.ruud.org | http://ruud.org
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 20:21:06 GMT
David Wagner wrote:
> If we assume for the moment that this published experience is
> representative, this suggests that the way to break real-world
> systems is not to study block cipher cryptanalysis but instead
> to study systems issues.
> Thus, I see no reason to believe that the folks with a proven
> track record at breaking real systems will be especially good
> at analyzing block ciphers.
That's a non-sequitur, because much of the success at breaking
real systems *is* due to exploiting what you call "systems issues".
Just to take a now well-known example, if some people had been
faced with the VENONA intercepts, (one presumes, based on analogy
with their other arguments) they would have argued "we know that
one-time pad systems can't be solved by analysis" and thus would
never have tackled, much less cracked, VENONA. But the people
with practical experience suspected that there would nonetheless
be vulnerabilites, so they looked for them.
But actually I had in mind the observation that most of the
public-sector cryptologists haven't exhibited the ability to
crack even the classical systems such as Hagelins, indicating
absence of knowledge of essential basic methods and tools of
cryptanalysis. Thus, their lack of success in cryptanalyzing a
new cipher system should be seen in context -- even if it were
readily breakable, would they have broken it? The answer seems
to be "not necessarily". So people who take such lack of
successful breaking as indicative of cryptosystem strength must
be making unwarranted assumptions.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 20:23:01 GMT
[EMAIL PROTECTED] wrote:
> ... 99% of the time brute force is the easiest (or only way)
> method to attack a message.
Easiest, perhaps, but "only"? There's another amazing claim.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 20:25:09 GMT
David Wagner wrote:
> See Rijmen and Preneel's work on "trapdoor ciphers" for an example
I appreciate the reference, but it's not an AES-like design.
The suggestion was that an AES candidate could have such a
back door, and I don't see how it could be managed without
being suspected.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 19:46:12 GMT
In article <7p6rra$21m$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Er, even the first three assumptions suffice to conclude that 80-bit
keys
> are within reach, within days. No need to tie up the machine for 6
months.
>
> 100x efficiency gain => 7 bits
> $25 billion / $250k => 17 bits
>
> 56+7+17 = 80
That's rediculus. To find a 80-bit key in say one day, you would have
to search 2^63.60 keys a second. You could do it on a parallel network
of a billion crackers at a rate of 2^33.6 keys a second but that's
still quite high. Even the best crackers on x86 computers search
about 2^19 keys a second (for rc5des on my 686 MII).
Assumming you can check one key per cycle that is 8,589,934,592 Mhz
chips ... (8,589 Thz cpus ...)
To find an 80-bit key in one year you would have to test 2^55.08 keys a
second. On a billion computers... you get 2^25 keys/sec which is
possible, saying you could get a billion of those computers...
I think the best even NSA could get is about 2^23 computers running at
most 2^30 keys/sec (if they are truly that fast). That is 2^53 keys a
second. It would take about 2^26 seconds or 2.12 years (avg.). This
however is unholily fast though (2^30 keys/sec).
I still think at least for 5 to ten years (unless some real big fabs
breakthru happens) 80-bit keys will be years out of reach.
For a AES 128-bit key (which is the smallest) you have to try 2^111.6
keys a second ...
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: chat sessions?
Date: Sun, 15 Aug 1999 20:41:52 GMT
In article <[EMAIL PROTECTED]>,
*@spam.ruud.org wrote:
> [EMAIL PROTECTED] writes:
>
> > I am so sorry. How about 3PM GMT (that's 10AM my time, and 10PM
your
> > time) for next sunday?
>
> 3pm GMT is actually 5pm my time. Sounds OK.
I thought you were +7 GMT...
Anyways, seen you there next week.
I will still be there tonight for a bit if anyone else is near my
timezone.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: chat sessions?
Date: Sun, 15 Aug 1999 21:09:22 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> > Can anyone make it for say 10 minutes at least tonight (1AM GMT)
just
> > to get an idea of who can show up (or responsed to the posts here)?
>
> Yeah, I'll bring some friends too.
>
Cool I am there right now.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: Wrapped PCBC mode
Date: 15 Aug 1999 21:16:49 GMT
>Can someone name me one benefit of Dave's 'super-duper' W-PCBC mode?
It allows him to take a horribly weak algorithm and (by running it 15 or 25
times) make it strong enough to withstand the attacks of the people who spend a
few minutes looking at it. Seriously, I wonder if anyone could break the
following: W-PCBC using four round blowfish (where Scott has his s-box) run
for about six rounds.
David Bauer
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 21:18:11 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > ... 99% of the time brute force is the easiest (or only way)
> > method to attack a message.
>
> Easiest, perhaps, but "only"? There's another amazing claim.
Well most iterative attacks don't work on messages. Only on severe
network connections. So I would think 99% of the time brute force is
the only method.
Unless of course there are inheriant flaws in the system, then you are
right it's not the only way. but for the most part (i.e PGP mail) it
is. (unless PGP has flaws... ?)
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 23:00:42 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>> But I prefer the features that should be found
>> on future ciphers for files. Namely a one bit change in input cahnges
>> the whole file out.
>
>What's the use of it?
The main reason for this is so that the whole file would
have to be used for an attacker to break making it harder to
break. Also if one use small common pharses the data is
not spread out so it ie easyer to attack if it has the so called
error recovery feature.
>
>It should be enough to add a checksum to find the error.
No this just gives the attaker more infomation
>
>> One where the entropy of message is spread
>> a lot better than the AES small black cipher with tiny keys.
>
>Why?
same anwser as above.
>
>> ...
>> Actually I prefer using pass pharse that are easy to rember too
>
>But what is the use of a huge key that contains only a small amount of
>entropy?
The huge key is just a consequence of the message. It is easier to
change to a different keyenc.key file once in a while than having some
fixed scheme to expand the key to fit the S-Box far better to let the
users have a choice of any single cycle S-Box.
>
>> ...
>> The design methods of the AES
>> candidates means they can't be good for file or serious message
>> protection.
>
>Why do you think so?
>
>All AES candidates were developed to withstand all known attacks.
>
>All of them are using more rounds than neccessary and the developers
>tried to add as much security as possible against unknown attacks (the
>unkeyed rounds in MARS, for example).
They were not developed to minimize the possible recovery based on
information theory. They where developed by people years behind what
the NSA is most likely using. A smart person serious about encryption
would assume in the design that some one could be more clever than he is.
So the design should use the most amount of computer resourses for the
job that can be talerated while minimizing the possiblity of solutions.
..
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
