Cryptography-Digest Digest #88, Volume #10 Sat, 21 Aug 99 07:13:02 EDT
Contents:
Re: I HOPE AM WRONG (Boris Kazak)
Re: I HOPE AM WRONG (Boris Kazak)
Re: NIST AES FInalists are.... (David A Molnar)
Re: NIST AES FInalists are.... ("Dorina M. Lanza")
Re: NIST AES FInalists are.... ("Dorina M. Lanza")
Re: NIST AES FInalists are....
SV: [Q]:Got a RSA private key on CRT format, how can I find e and d? ("Claes & Gunn
Irene")
Re: I HOPE AM WRONG (vincent)
Re: NIST AES FInalists are.... (David A Molnar)
Re: Ciphile Software (David A Molnar)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: E2 (David Wagner)
Re: What is "the best" file cryptography program out there? (Gurripato)
----------------------------------------------------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: I HOPE AM WRONG
Date: Fri, 20 Aug 1999 20:45:20 -0400
Reply-To: [EMAIL PROTECTED]
vincent wrote:
>
> > >I don't believe that "boo koo" is correct. I'm going to hazard a guess
> > >that you both intend to use the French word "beaucoup", meaning "many"
> > >or "a lot".
> > Yeah I guess that was what I meant. I hate reading but like talking
> > so I spell most things as they sound. if "beucoup" sounds like
> > "boo koo" then that is what I meant.
> >
>
> Eh les gars, j'ai une superbe idee, et si maintenant on se mettait a
> parler francais uniquement, ca changerait, en plus c'est pas une idee si
> eloignee de la cryptographie, en effet, qui peut bien comprendre cette
> vieille langue decrepie qu'est le francais?
>
> Alors qu'est-ce que vous en pensez ?
======================
C'est une idee vraiment superbe, moi je suis entierement d'accord.
Le seul obstacle, quand meme mineur, sera le fact que je suis
d'origine Russe et ne suis pas si proficient en langue Francaise
que les parleurs natives.
Parlant un argot cryptographique, le langue Russe avec son
alphabet cyrillique est une approximation beaucoup plus proche a
un ideal du ciphre forte. Meme les cracqueurs ordinatrices ne
pourront pas reconnaitre un tel texte parmi le abondance des
caracteres non-ASCII. Voila!
Au bientot BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: I HOPE AM WRONG
Date: Fri, 20 Aug 1999 20:50:09 -0400
Reply-To: [EMAIL PROTECTED]
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, vincent <[EMAIL PROTECTED]> wrote:
> >> >I don't believe that "boo koo" is correct. I'm going to hazard a guess
> >> >that you both intend to use the French word "beaucoup", meaning "many"
> >> >or "a lot".
> >> Yeah I guess that was what I meant. I hate reading but like talking
> >> so I spell most things as they sound. if "beucoup" sounds like
> >> "boo koo" then that is what I meant.
> >>
> >
> >Eh les gars, j'ai une superbe idee, et si maintenant on se mettait a
> >parler francais uniquement, ca changerait, en plus c'est pas une idee si
> >eloignee de la cryptographie, en effet, qui peut bien comprendre cette
> >vieille langue decrepie qu'est le francais?
> >
> >Alors qu'est-ce que vous en pensez ?
>
> As a favor to those whose French is a little rusty I put this through
> the Alta Vista Translator so any one with an English background would
> be as able to follow this as if I wrote it in English myself.
>
> in English:
>
> Do Eh the guy, I have superb a idee, and so now it was put has to speak
> French
> only, Ca would change, in more it is not a idee if eloignee of the
> cryptography,
> indeed, which can understand well this old language decrepie which is
> French?
>
> Whereas think you?
>
> 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
===========================
I don't know who was the author of this translating program, but the
result of translation is pure *ebonics*. Are you comfortable with it?
Best wishes BNK
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: 20 Aug 1999 21:08:59 GMT
[EMAIL PROTECTED] wrote:
> chosen plaintexts are available, because this is the
> appropriate attack model in the real world. Why not assume
> that "only" a thousand known plaintexts are available and
> compare the finalists under this assumption alone?
I can think of two reasons not to :
1) it's unlikely that attacks will be found which use only a thousand
known plaintexts before time is up. If that happens, it will leave us
with five ciphers all "equally secure" under that assumption.
2) more of a quibble, but a thousand known plaintexts may be too small.
Consider using AES to encrypt a high-bandwidth channel between two office
buildings, or between an office building and the outside world. If an
adversary can compromise part of the traffic, say by taking a job in the
building on one end, then it can gain access to large numbers of known
plaintexts.
To make this more concrete, imagine that I work in a company which uses
AES to encrypt data being sent to an overseas office. I can send anything
I want to my colleagues on the other end of the line, but I can't read the
CEO's mail. If both of our messages are encrypted with the same key over
the link (which hopefully they would not be), then a chsen-plaintext
attack aimed at recovering the CEO's mail is possible.
If we know that AES is vulnerable after seeing X chosen plaintexts with
the same key, howevr, then we can take steps to prevent this, say by
changing keys before that many blocks have been encrypted. It gives us
some idea of when it's not safe to use the cipher. Even if X is
"unreasonable" or "academic" in size, it's still some information.
> is interesting to think about how other parameters (weak
> keys, chosen plaintexts, memory, work, etc) should affect
> the attack cost function.
I like this idea much better. The cost may need to vary depending on
adversary, though.
-David
------------------------------
Date: Sat, 21 Aug 1999 00:36:44 -0400
From: "Dorina M. Lanza" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
[EMAIL PROTECTED] wrote:
> In article <7phvdg$4ea$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David Wagner) wrote:
>
> >Since the parameters for the AES competition are already
> >set for us by NIST, these real-world design principles are irrelevant
> >to the AES competition -- even if NIST's framework is somewhat sub-
> >optimal, it's probably too late to change it.
>
> I wonder. Surely the AES competition is not an academic
> exersize framed by NIST's specifications for the contest;
> after all the AES will be an important primitive in many
> real-world COMSEC systems. You cannot analyze primitives
> independently of their context. I think it would serve
> security better if the public researchers investigated for
> weaknesses in the AES finalists when only a few known or
> chosen plaintexts are available, because this is the
> appropriate attack model in the real world. Why not assume
> that "only" a thousand known plaintexts are available and
> compare the finalists under this assumption alone?
How would you feel about suggesting a cipher that had not been attacked by
a collection of billions of messages, some of which were designed (chosen
plain text) to expose as much as possible of the cipher, for a financial
network carrying easily millions, and possibly billions, of independent
transactions?
If the AES is to be all-things-to-all-people it must survive the worst
case attack. Your approach would indicate that we need tiers of ciphers.
That's easily feasible, but not by any conceivable government
process/decision/organization.
>
>
> I have suggested to NIST that in order to compare ciphers in
> a sensible manner a "cost" function for an attack must be
> agreed beforehand. I think this cost function should grow
> very quickly if too many known plaintexts are required. It
> is interesting to think about how other parameters (weak
> keys, chosen plaintexts, memory, work, etc) should affect
> the attack cost function.
How do you define "too many"?
------------------------------
Date: Sat, 21 Aug 1999 00:30:51 -0400
From: "Dorina M. Lanza" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
David Wagner wrote:
> It seems to me that NIST wants the AES competition to be about selecting
> a strong block cipher, not about building a strong COMSEC system.
> That says to me that we should get people who have successfully broken
> real-world block ciphers.
>
> Looking for people who have successfully broken real-world COMSEC systems
> would, I agree, be very useful. But I suspect they are going to say things
> like ``stream ciphers without ciphertext feedback are dangerous, because a
> very common failure mode is to reuse the same key'', or ``using ECB mode is
> very dangerous''. Since the parameters for the AES competition are already
> set for us by NIST, these real-world design principles are irrelevant to the
> AES competition -- even if NIST's framework is somewhat sub-optimal, it's
> probably too late to change it.
>
> To put it another way, I think my argument will have to stand or fall on
> the claim that analysis of AES block ciphers is largely orthogonal to analysis
> of real-world COMSEC systems. (One justification for this is that attacks
> on real-world systems never seem to attack the block cipher.)
The observation you've stated may be accurate, but it is also
explicable/expectable by thenature of the difference in the style of attack. An
attack on the underlaying math,
hardware/software implementation, or key space requires a large amount of
cryptographic skill/expertise or a large amout of computational resources, often
specific to a particular cipher.
The organizations having massive staffs or computational resources are not those
that
publish their results in the open literature. Thus we should not expect to hear
about
failures or successes, or even attempts to attack (analyze) the ciphers as opposed
to the systems of which they are a part.
They may well be orthogonal, but because we have no data about a particular axis
does not mean that activity is restricted to the axis we have data describing.
> If there is some dependency between the two, I admit that my whole argument
> falls apart. Are you suggesting that there is a dependency here that I'm
> missing, or are you suggesting something else entirely?
>
> I'm also assuming the debate is about analysis of AES candidates. If the
> debate is on a broader topic -- how to build strong real-world COMSEC
> systems -- then I will readily concede your point. One of the huge advantages
> the NSA has is 50 years of experience analyzing real traffic. There's
> really no easy way to get that experience in the academic world.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: NIST AES FInalists are....
Date: 21 Aug 99 04:13:37 GMT
[EMAIL PROTECTED] wrote:
: I wonder. Surely the AES competition is not an academic
: exersize framed by NIST's specifications for the contest;
: after all the AES will be an important primitive in many
: real-world COMSEC systems. You cannot analyze primitives
: independently of their context.
Well, the quality of an implementation of a block cipher is not affected
by which block cipher one uses. Some people will use block ciphers
properly, and some will be careless, and that won't be affected by which
AES candidate is chosen.
John Savard
------------------------------
From: "Claes & Gunn Irene" <[EMAIL PROTECTED]>
Subject: SV: [Q]:Got a RSA private key on CRT format, how can I find e and d?
Date: Wed, 18 Aug 1999 23:51:51 +0200
<[EMAIL PROTECTED]> wrote in message news:7o9me6$hbe$[EMAIL PROTECTED]...
> Hi, assuming that I have access to a RSA private key on the Chinese
> Remainder Theorem Format, can I then somehow calculate d and e?
> If so, how do I do it?
>
> kind regards
> Thora Sennils
Hi ..
If you have a privat key you will resive d.
If you wanna calculate e you need ( sorry no greek letters avaliable) phi
(n) OR the primes p and q.
>From CRT format ( Ai = Xi mod Mi )
------------------------------
From: vincent <[EMAIL PROTECTED]>
Subject: Re: I HOPE AM WRONG
Date: Fri, 20 Aug 1999 17:23:01 +0100
> >I don't believe that "boo koo" is correct. I'm going to hazard a guess
> >that you both intend to use the French word "beaucoup", meaning "many"
> >or "a lot".
> Yeah I guess that was what I meant. I hate reading but like talking
> so I spell most things as they sound. if "beucoup" sounds like
> "boo koo" then that is what I meant.
>
Eh les gars, j'ai une superbe idee, et si maintenant on se mettait a
parler francais uniquement, ca changerait, en plus c'est pas une idee si
eloignee de la cryptographie, en effet, qui peut bien comprendre cette
vieille langue decrepie qu'est le francais?
Alors qu'est-ce que vous en pensez ?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: 21 Aug 1999 06:37:18 GMT
Dorina M. Lanza <[EMAIL PROTECTED]> wrote:
> The organizations having massive staffs or computational resources are
> not those that
> publish their results in the open literature.
What is the largest and best equipped organization which regularly posts
in the open literature, by the way?
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software
Date: 21 Aug 1999 07:25:46 GMT
In sci.crypt [ Dr. Jeff ] <[EMAIL PROTECTED]> wrote:
> Okay, so no one in sci.crypt has any idea about or interest in talking
> about Ciphile Software's Original Absolute Privacy Level 3 software.
> Why is that? Is the software not considered good? Do people have
> something against Anthony on a personal level? What gives?
I don't know Anthony. At all. I have nothing against him personally.
Here's why I have not spent much time on OAPL3 :
The claims which have been made about the software, both on Anthony's
postings and at www.ciphile.com seem very strange. That would not be so
bad by itself, except that they unfortunately sound very much like claims
which have been made about systems which turned out to be very weak.
Here's an example of a claim which I find "very strange" :
"Uses no mathematical equations so there are none of the associated
security risks!"
I find it difficult to conceive of encryption which can't be expressed by
the equation
C = E(M)
where C is the ciphertext, M is the message, and E is the encryption
mechanism. The web page says that the system is related to the
one-time-pad; well, in that case, a possible expansion of the above
equation could be
C = (pad part) XOR M
where (pad part) is one of the many pseudo-one-time-pads generated by the
software. The thing is, I don't know this for sure. It is only conjecture,
since the site does not elaborate what it means by "not using any
mathematical equations." Nor do I know what the security risks of using
equations are.
I would like more detail. As it is, I say nothing about OAPL3 because
there's nothing I can say -- the web site is nowhere near specific enough
for me to make any sensible comment, and I haven't reverse engineered
their software. I'm not even sure if I can get source code!
For all that's said about David Scott and his system, at least he
provides free source code for his ciphers and will answer questions.
Many, MANY other ciphers like the AES candidates have nice descriptions of
the exact details of their workings that I can read. Still other ciphers,
like Mercy, have distinguishing characteristics (in Mercy's case, a LARGE
block size) which make them very interesting to look at and worthy of more
discussion than they currently receive.
Life is short. And I'm not even that familiar with block ciphers; it's
very hard for me to say much non-stupid about them at the moment (I keep
promising myself that I'll sit down with Schneier's course recommendations
and change this but...). So why should I spend my time on OAPL3?
The other objection I mentioned stems from the fact that lots of systems
which have described themselves as "pseudo-one-time-pads" have turned out
to be a bunch of really crappy random number generators operating on a
shared secret. To escape from that shadow, OAPL3 needs to do something to
differentiate itself. Giving its methods combined with a demonstration of
security against some plausible attacks would be a GOOD STEP IN THAT
DIRECTION.
> Fwiw, I'm not in any way associated with Ciphile Software except as a
> person interested in cryptography and all software that accomplishes
> it. OAPL3 does the job quite well.
What do you mean by "quite well" ? By this question I mean : "do you mean
it encrypts and decrypts correctly, or that it seems secure for reasons
which you've verified, or something else?"
Thanks,
-David (who posted something much longer and wordier than first intended.
sorry. )
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Fri, 20 Aug 1999 18:46:18 +0200
SCOTT19U.ZIP_GUY wrote:
>
> First of all the proof is in the working program. Find an example
> od where a file that when being decompressed and then compressed
> again does not back to the same and you haev found a error
>
> the file ... xxxxxxxy yyyyyyyy would decompress to what I guess
> you want.
> the file xxxxxxxxy and the last byte gone would decompress to
> something different. But when you compress the file you got from
> decompressing you get a file that ends with xxxxxxxy
But you can't decompress according to the Huffman scheme, because
suppose this first y following x is, say, 0, then, since 0 followed
by 8 bits is a valid Huffman code, 0 alone can't be a valid huffman
code (this follows from the principle of construction of the
Huffman tree). This proves that the algorithm after finishing the x's
and finding the first y (here 0) can't do anything anymore. Isn't that
clear?
>
> The coding is such that xxxxxxxy yyyyyyyy and xxxxxxxy yyyyyyyy
> can not decompress to the same file since the compression decompression
> all map "one to one"
> now that being said if y = "0" then since it started after the last string
> it would mark the end of file in the short version. If Y='"1" in the
> short version then the last symbol decompressed would be 1111... up to at most
> 8 1's tell a valid symbol is decoded.
>
Are here some printing mistakes or what? (You repeated the
same string 'xxxxxxxy yyyyyyyy'. They are identical. Why will
they not be processed to the same?) But this remark is not important.
Essential is that you comment on what I answer to your previous
paragraph above.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: E2
Date: 17 Aug 1999 16:30:45 -0700
In article <7pamrr$ljk$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Is anyone else disappointed that E2 was not chosen as an AES finalist?
E2 is an interesting design, but truncated differentials were found for an
unexpectedly large number of rounds, and many competitors were much faster.
I would have put it at around #6.
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: What is "the best" file cryptography program out there?
Date: Sat, 21 Aug 1999 10:44:52 GMT
On Thu, 05 Aug 1999 19:56:29 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (KidMo84)
>wrote:
>>You know, i always wonder what the NSA has broken but has not released to the
>>public yet:).
>>
>>Signed,
>>KidMo
>
> I think is is a safe bet that most of the high praised programs are broken by
>the NSA and that would include the NSA candidates. If one is truely concerned
>you should use several methods in series. But if you do this be sure to use
>methods that have no headers or change the file lenght. You can use my code
>as one of the methods since it will not change the file length and if any one
>bit of the file changes the whole file changes.
>
I disagree. There�s no proof that the NSA can break (=use a
method more efficient than brute-force) DES. In fact, seems like DES
was built to withstand cryptanalytical techniques unknown then to the
civilian world.
------------------------------
** 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
******************************
