Cryptography-Digest Digest #176, Volume #10 Sat, 4 Sep 99 19:13:02 EDT
Contents:
Re: Does SSL use RSA Keys? (Bodo Moeller)
Re: NSA and MS windows ("Roger Schlafly")
Re: Schneier/Publsied Algorithms (SCOTT19U.ZIP_GUY)
Re: NSA and MS windows (David Wagner)
Re: NSA and MS windows (David Wagner)
Re: SQ Announcement (David Wagner)
Mystery inc. ([EMAIL PROTECTED])
Re: Description of SQ (David Wagner)
Re: Description of SQ (David Wagner)
Newbie needs help ("B3avis")
Re: Correction to Uhr Box Description (John Savard)
Re: THE NSAKEY (C. Peter Constantinidis)
Re: Newbie needs help (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Does SSL use RSA Keys?
Date: 4 Sep 1999 17:47:53 GMT
Eric Young <[EMAIL PROTECTED]>:
> 2) Encryption with an 'ephemeral key' and signing that ephemeral key
> with the servers private key.
[...]
> For 2), RSA or DSA server keys can be used with a temporary
> DH or RSA key.
[...]
> Unfortunately 2) is much more expensive. DH key generation is
> reasonably cheap, but RSA key generation is not. Normally
> an ephemeral RSA key would be reused a few times for performance
> reasons. Also, since the server has to perform a signing
> and decrypt (or the equivalent expensive DH operation), the
> load on the server for option 2) is much greater than option 1).
DH can be done faster than RSA because for 1024-bit DH a subgroup size
of about 160 or 165 is enough -- this means the server has to do two
exponentiations with 160-bit exponents for ephemeral DH, while it
would have to do one exponentiation with a 1024-bit exponent for a
temporary RSA key (if RSA keys of that length were permitted by the
TLS standard). It's a shame that neither Netscape nor Microsoft nor
even Opera Software have implemented the DHE ciphers in their browsers
-- unless when using export cryptography (where the short session keys
are the weakest link in the chain) you don't get any forward secrecy
with those browsers.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Sat, 4 Sep 1999 10:44:10 -0700
pbboy wrote in message <[EMAIL PROTECTED]>...
>NSA : "P-p-p-please sign this thingamajig, Mr. Gates. I'll do anything
>you want...I'll be your best friend...!"
>Gates: "HA! Lick my feet! Bow to me, the omnipotent Gates!"
>NSA: *Lick-lick-slobber-slobber* (wipes crusties from mouth, removes gum
>from forehead) (*sniffling*)"Now w-will you sign it?"
>Gates: "No! Do it again, just so you know who's boss!"
<chuckle>
>I don't think so.
>
>Maybe I overestimate the NSA's power, but why would the NSA _ask_ MS for
>anything?!? This is a game, people!
MS is not that powerful yet. MS had to get permission to export CAPI.
If the NSA put minor conditions on the export approval, then MS would
go along with them. Above all, MS wants to make money.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Schneier/Publsied Algorithms
Date: Sat, 04 Sep 1999 20:19:20 GMT
In article <[EMAIL PROTECTED]>, Eric
Lee Green <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> >cryptographic strength). My understanding is that the typical criticism
>> >of your program is that it's rather slow for the amount of cryptographic
>> >strength provided.
>> And naturally you belive that with out even trying it. People have
>> compared the speed of scott16u to blowfish and it was not that slow.
>> The real time hog is the actual seting up of the S-box. But that can
>> be done independent of the actaul encryption.
>
>You are correct that I have not run your program. I am a Unix software
>developer and do not run Windows. When I'm not running FreeBSD, I'm
>usually running Linux. (We also have Sun, DEC, AIX, etc. machines in our
>software porting lab, but Linux makes a lot cheaper Unix software
>development station so as we've grown we've retired our old workstations
>to the lab and gone all-Linux for the workstations).
I have not tried my code on a Linux port but I assume it would run
about the same since all my stuff is nothing more than the DJGPP port
of GNU for the PC.
>
>All that aside, your algorithm would not work for us anyhow because we
>must be able to decrypt the outcoming data stream as it comes over the
>network, because we are sending the output to different locations and do
>not have the necessary storage to buffer it all for future decryption.
>This is a case where a traditional block cipher is the right solution
>(our application pre-blocks the data in the first place, since the
>output devices are block devices).
If one wants my methods are adjustable for variouos block sizes. I just
use a whole file as a single block but there is no reason someone could not
use 2389 bits if that block size is convinent.
>
>> >tell RC5 seems to be considered secure). The NSA's choices for finalists
>> >seem to be pretty close to what the public community predicted before
>> >the finalists were announced.
>> >
>> >In addition, at least two of the AES candidates are based on prior work,
>> >i.e. RC6 is basically a derivative of RC5, and Twofish is a derivative
>> >of Blowfish. Both RC5 and Blowfish have been hit on pretty hard, making
>> >it unlikely that their derivatives have a weakness that would allow
>> >anybody to crack them in significantly less time than is currently
>> >conjectured.
>> >
>>
>> I think you greatly underestime the strength of the NSA decrpytion
> ability.
>> As well as there ability to make current research go in the wrong direction.
>> They use any and all means to prevent the world from having safe encryption
>> The microsoft thing is just the tip of the iceberg.
>
>When it comes to ciphers, I don't think that I'm underestimating them by
>much. The problem with ciphers is how to recover either the key or the
>message from what is to all appearances random noise. I'm sure the NSA
>has methods we don't know about, but even the NSA cannot change the laws
>of mathematics, and this is an area that has been intensely studied over
>the years since the late 40's -- there's just not much left to suck out
>of that husk.
>
>On the other hand, public key encryption (like in the "microsoft thing")
>is a fairly new field (and there has been an insinuation that actually
>it's an older field, that the NSA had it for years before Shapir et. al.
>let the genie out of the bottle), and yes, I agree with you that the NSA
>may have methods that significantly compromise the existing schemes. We
>just haven't been doing the math in this area for long enough to have a
>large degree of confidence, and if the hints about the NSA's past
>capabilities are correct, the NSA *has* been doing the math in this area
>for a significantly longer time. Schneier may dismiss the possibility
>of some quantum leap in mathematics making current public key schemes
>insecure, but looking at the slow growth of mathematical knowledge over
>the years and how so many "impossible" problems have taken decades or
>even in some cases centuries to crack, I have to remind folks that the
>field of mathematics operates in generational time, not in Internet time
>-- and the NSA has been doing research in this area for a generation.
>
>But then again, for my particular application I don't care much if the
>NSA can crack it, as long as random criminals can't crack it. I suspect
>that it won't even be operated in encryption mode most of the time,
>because most of the data is pretty ordinary stuff that has no real
>privacy implications sent over a switched private LAN, and strong
>authentication is all that's needed there. A few banks have asked for
>encryption capability, but even there the NSA is not the boojum (most of
>these banks probably already cooperate with the NSA and give the data
>plain-text to the NSA, though none will ever admit it, no more than AT&T
>admitted giving all international telegrams to the NSA), random
>criminals are, and if it keeps criminals from inserting their own
>account numbers into the data as the destination of deposits, and keeps
>criminals from sniffing information that can be used for non-crypto
>attacks in the "real world", it's done its job.
>
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
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NSA and MS windows
Date: 4 Sep 1999 12:54:54 -0700
In article <[EMAIL PROTECTED]>,
Bruce Schneier <[EMAIL PROTECTED]> wrote:
> If I were going to Trojan a crypto API, I would weaken the random
> number generation process.
Yes, and it's trivial to do. Ian Goldberg and I tried the exercise for
Netscape Navigator several years ago, and it took an hour or two. It's
just a 4-byte change (NOP out the call to the procedure that initializes
the RNG with entropy, and you're done).
Lopping off the head of the RNG is much easier to do than inserting a
bogus CryptoAPI module, and is much harder to detect as well.
This _NSAKEY stuff in the newspapers is, IMHO, primarily hype and FUD.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NSA and MS windows
Date: 4 Sep 1999 12:57:46 -0700
In article <7qqgs3$oan$[EMAIL PROTECTED]>,
Roger Schlafly <[EMAIL PROTECTED]> wrote:
> Maybe. Perhaps someone from the NSA suggested using a
> backup key, and the MS programmers called it the NSA key.
That is indeed what the MS techies are claiming. It's hard to
verify with 100% certainty, but it's certainly not an implausible
explanation.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: SQ Announcement
Date: 4 Sep 1999 13:07:21 -0700
If I understand correctly, what you are calling the "Information Lose"
theory is roughly the same as Shannon's theory of information-theoretic
security.
Yes, there are some ciphers which Shannon's theory lets you _prove_ to
be secure (the one-time pad is the canonical example), but they all have
a fundamental limitation: the size of the key must be at least as large
as the size of the plaintext encrypted. As a result, information-theoretic
security is widely considered impractical for real-life use.
So, if the "Information Lose" theory is equivalent to Shannon's theory,
it too will have the same limitations.
Can you tell me whether the "Information Lose" theory somehow avoids the
limitations of Shannon's theory? I read through your thesis, and it looks
to me that they share the same disadvantages, but I couldn't tell for sure.
------------------------------
Date: Sat, 04 Sep 1999 20:33:47 +0100
From: [EMAIL PROTECTED]
Subject: Mystery inc.
Looking for somewhere to discuss possible "real world" ciphers such as
Poe and Beale.
Where people can exchange and share their thoughts, info. and progress
in such ciphers.
sha99y
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Description of SQ
Date: 4 Sep 1999 13:14:44 -0700
In article <7qqooh$[EMAIL PROTECTED]>,
Kostadin Bajalcaliev <[EMAIL PROTECTED]> wrote:
> Consider replacing {1} by
> > {1'} A=P[Sr]; B=P[V[P[A]]];
> >Then the modified cipher becomes insecure, for some keys.
>
> Just read the thesis, this situation is explained, no more that 2 recurzive
> look-ups P[P[x]]
I disagree. I don't think your comments in the thesis apply here.
You state
``having structures like P(P(P(x))) is also dangerous because it
is possible P to have cycles and this recursive formation will
ignore itself in some number of cases producing loss of entropy.''
In other words, you suggest that a double-lookup P[P[x]] is bad because
this loses some entropy: if P[] has cycles of length 2, P[P[]] will have
cycles of length 1.
But the modification above avoids the problems of short cycles causing
loss of entropy by using a V[] lookup in between the P[] lookups. Even
if P[] has any cycles of length 2, P[V[P[]]] will not necessarily have
cycles of length 1.
So the situation is different here. I think I gave a valid example.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Description of SQ
Date: 4 Sep 1999 13:27:26 -0700
In article <7qqooh$[EMAIL PROTECTED]>,
Kostadin Bajalcaliev <[EMAIL PROTECTED]> wrote:
> But you have missed two things.
I don't think so. Maybe I did not explain the attack clearly enough.
I will try to do better below.
> P rotates but V does not. So in the second iteration they are going
> to be in opposite position lsb(P[i])=1-lsb(V[i]); So the swap will change
> the lsb property of P because P[A] will retain lsb property but not
> P[V[P[a]]];
No, I think the lsb properties behave as I stated.
Before the second iteration, we have
lsb(P[i]) = 1-lsb(i), lsb(V[i]) = lsb(i) for all i.
Just before step {2} of the second iteration, we have
lsb(A) = lsb(B) = 1-lsb(Sr).
In {2}, first we do `V[A]=B;', and since lsb(A)=lsb(B), this doesn't
disturb the lsb-property for V. Then we do `Swap P[A], P[B];', and
since lsb(P[A])=lsb(P[B]), this doesn't disturb the lsb-property for P.
I specifically use the fact that P rotates but V does not.
Please reread my original explanation.
> And the second thing that is part of the algorithm is Sr<<<1. If
> your case happened than there is no chance all the bits to be threaten is
> this way, so Sr<<<1 will practically save the situation, msb of Sr became
> lsb for the next iteration, and if msb is secure bit the whole sequence is
> safe.
No, this doesn't matter. I don't care what the value of Sr is;
it can be anything.
The only reason I even mention Sr is because I first prove that
lsb(A) = lsb(Sr) and lsb(B) = lsb(Sr); then I use that to prove
that lsb(A) = lsb(B); and from then on, Sr is irrelevant.
Maybe my explanation of this point was unclear, but I don't think
it was wrong.
Here is part of my original explanation, repeated:
> >Consider: After the first step of initialization, we have
> > lsb(P[j]) = lsb(j) for all j,
> >where lsb(x) = x mod 2 stands for the least significant bit of x.
> >Suppose a similar condition holds for V (which is a L-bit condition on
> >the 8L-bit key). Then at the first SQ1() iteration, we have
> > lsb(A) = lsb(P[Sr]) = lsb(Sr)
> > lsb(B) = lsb(P[V[P[A]]]) = lsb(V[P[A]]) = lsb(P[A]) = lsb(A) = lsb(Sr)
> >and thus the first half of step {2} (`V[A]=B; Swap P[A], P[B];') doesn't
> >disturb the lsb-properties of V or P. The rotation `P<<<1' changes the
> >lsb-property on P[] to a new one, namely lsb(P[j]) = 1-lsb(j) for all j.
> >
> >Now look at the second iteration. After step {1'}, we have
> > lsb(A) = lsb(P[Sr]) = 1-lsb(Sr)
> > lsb(B) = lsb(P[V[P[A]]]) = 1-lsb(V[P[A]]) = 1-lsb(P[A]) = lsb(A) =
> 1-lsb(Sr)
> >Again, the first half of step {2} (`V[A]=B; Swap P[A], P[B];') doesn't
> >disturb the lsb-properties of V or P. Finally, the rotation `P<<<1'
> >returns the lsb-property on P[] to lsb(P[j]) = lsb(j) for all j.
> >
> >After two cycles, we're back to where we started (in terms of the
> >lsb-properties of V[] and P[]). By induction, after any even number of
> >cycles, the lsb-properties for V[] and P[] will always hold, if your
> >key is of the special form mentioned above. In this case, lsb(Out) will
> >form the sequence 0,1,0,1,0,1,0,1, and thus this situation is readily
> >detectable.
> >
> >In other words, 1/2^L of the L-byte keys are very weak for this
> >modification of the cipher. Does the "Information Lose" theory predict
> this?
------------------------------
From: "B3avis" <[EMAIL PROTECTED]>
Subject: Newbie needs help
Date: Sat, 4 Sep 1999 23:10:37 +0200
Hey there. I am rather new at encryption and decryption, but I can handle
some programming (Delphi, Borland). I want to knwo some basics, like :
how does the stream-thing work ?
how can you make your own algorithms ?
what things are good, what things aren't good ?
...
Can somebody help me ?
Source-code would be also very apreciated.
Thanks, B3avis
http://come.to/bchicken
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Correction to Uhr Box Description
Date: Sat, 04 Sep 1999 21:06:03 GMT
[EMAIL PROTECTED] () wrote, in part:
>As a result, I have made the appropriate corrections to my description of
>the Uhr box at
>http://www.ecn.ab.ca/~jsavard/ro020402.htm
>although my original hypothetical reconstruction is also still mentioned.
>As it was wrong, I only left one of the diagrams of that reconstruction on
>the page; I haven't drawn any diagrams of the real Uhr box just yet.
Well, now there is a diagram of the real Uhr box. It isn't as pretty,
though, as the one of my imaginative reconstruction; the rotor is
noted schematically instead of being drawn in the round.
In other topics, a page on four-dimensional polytopes is coming. (I
recently added a couple of links on that topic.)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (C. Peter Constantinidis)
Crossposted-To: talk.politics.crypto
Subject: Re: THE NSAKEY
Date: Sat, 04 Sep 1999 21:18:13 GMT
On Sat, 04 Sep 1999 03:48:41 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
>It also makes me wonder about the security of Blowfish
>or Twofish.
Statements like that make me wonder about the security of scott19u.zip.
P.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie needs help
Date: Sat, 04 Sep 1999 22:35:25 GMT
In article <7qs27g$9f4$[EMAIL PROTECTED]>,
"B3avis" <[EMAIL PROTECTED]> wrote:
> Hey there. I am rather new at encryption and decryption, but I can handle
> some programming (Delphi, Borland). I want to knwo some basics, like :
> how does the stream-thing work ?
> how can you make your own algorithms ?
> what things are good, what things aren't good ?
Well... hmm that's very ambiguous. I would suggest studying bit arithmetic
then take a look at some attacks and how they apply. I would also look at
various constructs like sboxes (algebraic and random, or both), rotations,
bit swaps (permutations), affine mappins (ax + b, type) decorrelation..
by no means can you learn everything at once, but if you read enough and get
a good look at what crypto really encompasses you can find an area to focus
on.
You can make your own algos in C if you want to test them... I would try to
have some idea or theory before you start...
>
> Can somebody help me ?
> Source-code would be also very apreciated.
Source code? but why? Crypto is not only about C code....
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.
------------------------------
** 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
******************************
