Cryptography-Digest Digest #39, Volume #11 Wed, 2 Feb 00 14:13:01 EST
Contents:
Re: Security of Kremlin (PC software): Insecure implementation? (Keith A Monahan)
Re: KEA gains something with RSA instead of D-H (Doug Stell)
Re: How to Annoy the NSA (Jerry Coffin)
Re: Block chaining (zapzing)
Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP (Darren New)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Sbox construction idea (Mike Rosing)
Re: Does the NSA have ALL Possible PGP keys? (Paul Koning)
Re: Does the NSA have ALL Possible PGP keys? (Paul Koning)
Re: Jaws Technologies' L5 Data Encryption Algorithm? (Paul Koning)
Re: Q: current CAST status (Mike Rosing)
Re: How to Annoy the NSA ([EMAIL PROTECTED])
Re: Terms need explain (Mike Rosing)
Re: How to Annoy the NSA ("Robert J. Clark")
Re: How to Annoy the NSA ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Security of Kremlin (PC software): Insecure implementation?
Date: 2 Feb 2000 16:15:24 GMT
Hi Paul,
Paul Schlyter ([EMAIL PROTECTED]) wrote:
: There are plenty of ways to implement this. One way is to, before
: encryption, add a header or a footer, with known contents, to your
: file before it's encrypted. After decryption with a bad key, the
: header or footer won't contain what's expected, and the program then
: knows the key was wrong.
I know you mentioned the hash was a more secure way but I'm interested
in quantifying how much additional risk there might be by providing
a known plaintext -> ciphertext pair by using a header and a footer.
I know algorithms are supposed to withstand known plaintext attacks,
but providing any more information to the attacker CAN'T be good.
Is it something to be concerned about and avoid?
Keith
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: KEA gains something with RSA instead of D-H
Date: Wed, 02 Feb 2000 16:17:15 GMT
On Wed, 02 Feb 2000 01:19:25 +0000, David Hopwood
<[EMAIL PROTECTED]> wrote:
David Hopwood provided a very good description of KEA. It helps if
someone thinks of KEA a simply a dual D-H, where each exchange is
semi-ephemeral, i.e., it authenticates one party and allows the other
party to contribute randomness to the session key.
>I don't see how KEA [KEA] can be adapted to use RSA without completely
>redesigning it, but maybe I'm missing something. Standard KEA (the
>key agreement protocol, rather than the email variant) is this:
>
> Alice and Bob agree on parameters g, p, and q
> (q is the order of g in GF(p)).
While the use of DSA-style parameters is suggested in the
specification, it is not technically necessary. KEA works without
having a q-parameter.
> Alice has private key xA, public key YA = g^xA.
> Bob has private key xB, public key YB = g^xB.
> Alice and Bob are assumed to know each other's authentic public key.
> (Key validation: check that YA and YB are elements of the order-q subgroup)
>
> Alice: RA = g^rA mod p (rA is chosen randomly).
> Bob: RB = g^rB mod p (rB is chosen randomly).
rA and rB are q-size values
> Alice -> Bob: RA
> Bob -> Alice: RB
> Alice & Bob check that RA and RB are elements of the order-q subgroup.
Incidentally, the CA also checks that YA and YB are elements of the
order-q subgroup, before it signs the certificate. This is not in the
KEA specification, but is a part of the CA requirements. The KEA
specification is simply focused on the two communicants, rather than
the CA.
The reason for this check can be found in a paper by Lim and Lee.
> Alice: tAB = YB^rA mod p
> Bob: tBA = YA^rB mod p
> Alice: uAB = RB^xA mod p
> Bob: uBA = RA^xB mod p
> Alice: w = (tAB + uAB) mod p
> Bob: w = (tBA + uBA) mod p
As pointed out in yesterday's post, XOR or a hash could be used to
combine the two session key contributions. KEA just happens to use
addition.
> Alice & Bob check that w != 0, and derive a key from it (details omitted)
>
>This is quite similar to some of the MTI* protocols, for example
>MTI/A0 [HAC Protocol 12.53] and MTI/C1. It's also similar to a protocol
>I designed myself (unpublished, called SID-3-DH), in which the agreed
>value is g^((xA + rA)(xB + rB)), rather than g^(xB.rA) + g^(xA.rB).
>
>[This is more efficient than KEA, because
>
> g^((xA + rA)(xB + rB)) = (YB * RB)^(xA + rA)
> = (YA * RA)^(xB + rB)
>
>can be calculated by each side using only one modexp, not two.
This is faster than KEA by a factor of about 2.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
Date: Wed, 2 Feb 2000 10:01:18 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> [EMAIL PROTECTED] wrote:
> > conferences, periodicals, etc. which makes it
> > possible to infer what they were doing in the
> > past.
>
> Only if you don't mind making incorrect inferences.
...especially given an agency like the NSA that might consider it
perfectly reasonable to publish something about research _entirely_
different from where they spend most of their time, JUST to be
misleading...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Block chaining
Date: Wed, 02 Feb 2000 17:31:16 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> zapzing wrote:
> > No, it is a use of bandwidth. Last time
> > I checked storage capacities and
> > bandwidth were growing by leaps and
> > bounds.
>
> Feel free to sell "effective" bandwidth to your customers
> at twice the usual rates. I suspect you won't have many
> customers..
>
You are *totally* misrepresenting my position.
I *hate* it when people do that. Yuch!
*Please* don't do that again.
I am not talking about *just* doubling
the length of the message.
I'm talking about doubling it for a reason,
and one that I think is a good one.
If you don't think that what I am proposing
is worth the doubling in bandwidth, then you
can of course argue that, but please do not
misrepresent my position by implying that I
am proposing that the lenght of the message
simply be doubled without any benefits in return.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP
Date: Wed, 02 Feb 2000 17:47:54 GMT
Trevor Jackson, III wrote:
> This issue came up a few months ago. If every possible position in the
> observable universe is a computer that tests a key in the Fermi time and they
> all run until the breakdown of protons (1e31 years by a stale theory), then you
> need a key of ~870 bits to prevent it being found.
Cool!
> QC gives you around sqrt() advantage, so doubling the key yields about the same
> strength.
Ah! I didn't know that bit. Neat. Thank!
So, like, a 2048-bit key is way overkill. Good. :-)
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Wed, 02 Feb 2000 17:49:12 GMT
On Wed, 02 Feb 2000 09:09:56 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Shawn Willden
<[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>
>> Shawn Willden <[EMAIL PROTECTED]> wrote, in part:
>>
>> >Given independent keys. What if the same key is used for all three?
>>
>> That would be very silly, and would hardly say anything about the
>> value of using three different ciphers.
>
>Maybe I misunderstand what Mr. Ritter is proposing. I had thought his
>idea was to use the same key with all the ciphers in a stack.
That is a big part of it.
>The point
>of using the same key was to allow the stack to be changed frequently.
Such is indeed the goal, but using the same key seems unnecessary. We
do not generally use the same message key for multiple messages even
now. Instead, we use a random keying value which probably will not
re-occur. And we can do the same thing while also changing ciphers.
I would like to see each "cipher" include sufficient key processing
(typically some sort of hash) to take a passphrase (or random string)
to internal key state. Given various ciphers with the same sort of
keying, we could simply swap one cipher for another, and the higher
level system would just continue to supply the same sort of keying
values for the next message.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Sbox construction idea
Date: Wed, 02 Feb 2000 12:00:24 -0600
Tim Tyler wrote:
> I'm obviously lost. 45^x mod 257 is linear in some sense...?
In the sense that it's a field and you could use the chinese remainder
thereom to (maybe) figure some things out.
> It seems to be the (correct) popular idea that - if you make s-boxes large
> enough you don't have to worry about their linearity any more - at work.
>
> Only a relatively small number of papers seem to discuss building large
> s-boxes out of lots of relatively small ones.
>
> The smallest s-boxes I've seen used are 4x4 ones. It appears to me that
> even smaller (i.e. 3x3) non-linear s-boxes could be profitably employed as
> "atomic building blocks" of larger s-boxes.
But nibbles and bytes are pretty easy to work with, and rom is so cheap
now that larger s-boxes are possible even in an FPGA. It's probably not
an interesting practical problem, but is sounds like an interesting
problem anyway.
> It's possible that making them smaller beyond a certain point loses its
> attractiveness in terms of faster operation and more iterations - but I
> doubt it.
The smallest is 1 bit. You don't have to think square, you can have n
bits
in and 2n bits out. Bus width is the speed determinant, so even an 8x16
sbox is pretty fast (one look up) on an 8 bit microcontroller.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Wed, 02 Feb 2000 12:54:34 -0500
Eric Lee Green wrote:
> ... 512-bit
> encryption, at least, seems well within the reach of pre-computing all
> possible PGP keys. It's estimated that there's approximately 2^86 of them,
No, the number is a whole lot bigger than that. A 512 bit key is made
up
of two 256-bit (approximately) primes. There are (2^256)/ln(256) primes
that size, i.e., over 2^253 of them. That's about 10^75. Perhaps
someone
confused powers of 10 with powers of 2?
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Wed, 02 Feb 2000 12:50:12 -0500
Johnny Bravo wrote:
> ...
> Or more likely they can't, but they don't need to. Is your home TEMPEST
> shielded? I seriously doubt it. The government can park a van outside
> your building and read everything on your screen, every keystroke you
> make.
Use Soft-Tempest fonts... (I'll have to convert those GIF files to
TTF files someday...)
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Jaws Technologies' L5 Data Encryption Algorithm?
Date: Wed, 02 Feb 2000 12:58:32 -0500
John Savard wrote:
> ... the fact that they've applied for a patent
> means that eventually they will be able to disclose their algorithm
No; if they have applied for a patent they can disclose the
algorithm *now*.
paul
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Q: current CAST status
Date: Wed, 02 Feb 2000 12:11:13 -0600
Hideo Shimizu wrote:
> Bruce Schneier wrote in Applied Cryptography (p.335),
> 'The Canadian government is evaluating CAST as a new encryption standard.'
> This statement is 1996's status. So, my question is what is the current
> status of CAST cipher? Have already CAST already been standard of Canada?
> If so, please tell me URL of Canadian encryption standard site.
Check this out:
http://www.entrust.com/s97is.vts down a ways under
Standards Supported by the Entrust Family of Products
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to Annoy the NSA
Date: Wed, 02 Feb 2000 18:00:00 GMT
In article <
[EMAIL PROTECTED]
ing.com>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8778es$r8d$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > You are wrong again. According to Science
> > Magazine (vol. 275, page 1570, March 14,
> > 1997) "hard" problems, or NP-Complete
> > problems "underlie nearly all cryptography and
> > computer security codes".
>
> You're getting things backwards: when Science Magazine publishes an
> article the contradicts Doug Gwyn (among others) about cryptography,
> it isn't _quite_ proof that the article you've read is wrong, but
> there's a LOT better chance that the article is wrong (or
> oversimplifying) than that he is.
>
Actually, Doug Gwyn is wrong and why should
anyone trust his opinion, especially vs.
Science Magazine. In message #5 of this
thread he wrote exactly, "RSA depends for its
security on the difficulty of factoring
products of large primes". By definition, it is
impossible to factor prime numbers!!! (Just to
be annoying- helloooo, people, helloooooo??? -
wakey, wakey).
> > If you don't believe
> > me then check out links like the RSAsecurity
> > link in my previous message and
> > www.cs.ccu.edu.tw/~ccc/student/dcl/dcl.htm
> > Despite the issue of NP-completeness, such a
> > quantum computer would have awesome power
> > for factoring.
>
> A quantum computer could factor quite a bit faster than a traditional
> computer, but keep in mind that much more complete and accurate
> descriptions are available than simply "awesome power". As a matter
> of fact, we already know _exactly_ how factoring can be done on a
> quantum computer and can simulate it on a conventional computer. We
> can figure out the number of steps involved in such a process.
> Equipped with that, we can figure out exactly how large of a key is
> needed with RSA (for one example) to completely thwart the attack well
> before it exists.
>
> > Everyone should know that Al Gore did not
> > invent the internet and that it was first
> > developed as a military project about 30 years
> > ago.
>
> As usual, you're getting things just about exactly backwards. ARPAnet
> was developed in the civilian sector as a way of helping communication
> between various places (mostly colleges and universities) doing
> research sponsored by the military. The funding (or part of it
> anyway) was provided by the military, but the technology was developed
> by the civil sector. The military provided some of the big servers in
> the early days of the Internet, but most of them were simply old
> computers that weren't being used for much else -- computers in active
> military use containing anything like classified information aren't
> allowed to be connected to the Internet at all.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Terms need explain
Date: Wed, 02 Feb 2000 12:23:14 -0600
Angus Lee wrote:
> --- Start qouting
> DS(KS) stands for the Digital Signature of Key Server
> K(KS)-certificate stands for key-exchange certificate for the Key Server
> S(KS)-certificate stands for signature certificate for the Key Server
> --- End qouting
>
> What're the meanings of:
> 1. digital signature;
> 2. key-exchange certificate; and
> 3. signature certificate
> in the above context?
It looks like (ks) is a subscript, so the key server is creating a
digital signature, or getting certificates. I have no idea what a
"key-exchange certificate" is, maybe another view of the key server's
public key from a CA? The last one may be something the CA can send
so you compare the first one and check for some kind of match.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Robert J. Clark" <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
Date: Wed, 02 Feb 2000 13:33:26 -0500
[EMAIL PROTECTED] wrote:
>
> In article <
> [EMAIL PROTECTED]
> ing.com>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <8778es$r8d$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > says...
> >
> > [ ... ]
> >
> > > You are wrong again. According to Science
> > > Magazine (vol. 275, page 1570, March 14,
> > > 1997) "hard" problems, or NP-Complete
> > > problems "underlie nearly all cryptography and
> > > computer security codes".
> >
> > You're getting things backwards: when Science Magazine publishes an
> > article the contradicts Doug Gwyn (among others) about cryptography,
> > it isn't _quite_ proof that the article you've read is wrong, but
> > there's a LOT better chance that the article is wrong (or
> > oversimplifying) than that he is.
> >
>
> Actually, Doug Gwyn is wrong and why should
> anyone trust his opinion, especially vs.
> Science Magazine. In message #5 of this
> thread he wrote exactly, "RSA depends for its
> security on the difficulty of factoring
> products of large primes". By definition, it is
> impossible to factor prime numbers!!! (Just to
> be annoying- helloooo, people, helloooooo??? -
> wakey, wakey).
You quoted his statement but obviously did not _read_ it. He did not
say "factoring prime numbers", he said "factoring the *products* of
large primes" (my emphasis).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to Annoy the NSA
Date: Wed, 02 Feb 2000 18:36:56 GMT
In article <
[EMAIL PROTECTED]
ing.com>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8781lf$esf$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > We can lengthen the codes of RSA but this
> > does not alleviate their fundamental
> > weakness- which is that it is not possible to
> > show how mathematically safe they are.
>
> You seem to have lost any connection to your original statements. If
> you'll recall, you were talking about quantum computing breaking
> nearly all current ciphers. Quantum computing has nothing to do with
> this at all...
>
The safety of RSA appears to depend on the
difficulty of factoring large numbers. This
factoring is considered very likely to be a
hard problem although it is not yet proven to
be so. It is also not proven that the safety
depends solely on the factoring. The main
point of Peter Shor's famous algorithm is that
it demonstrates that a quantum computer
could factor large numbers efficiently (i.e.
within polynomial time). For anyone who's
interested, a good intro to codes and their
vulnerability is Simon Singh's "The Code Book".
> > This is why there is research into RSA variants,
> > quantum encryption, etc.
>
> I suspect that most people who've done research into forms of PK
> cryptography do it for reasons completely unrelated to quantum
> computing. Some doubtless do it simply because it's what interests
> them. Others object to using a patented algorithm. Still others want
> things like smaller keys. I've read a number of papers on methods of
> PK cryptography, and seen all sorts of reasons advanced for doing
> research into new systems, but not ONE of them has given quantum
> computing (or even hinted in that direction) as a reason for doing
> research into new algorithms.
>
> Quantum encryption is something else entirely, and has essentially
> nothing at all to do with the subject at hand.
>
Here's a quote from PC Magazine, "With
advances in information technology and
mathematics threatening to render public key
cryptography insecure in years to come,
quantum- key distribution promises to offer a
solution before the problem becomes too
pressing". Quantum Computing qualifies as one
of these threatening technological
advancements. Check out this link for an
example of a new cryptographic system that
was developed partly with the motivation of
avoiding obsolescence due to quantum
computing- www.bertaut.com/
cryptography.html
> > In general, all public key cryptosystems are
> > based on "hard" problems, or NP problems (this
> > is also stated at the RSASecurity link I gave
> > before).
>
> Well, at least now you're starting to speak about things in something
> approaching a realistic fashion: it MIGHT be possible to use a quantum
> computer to other PK algorithms than RSA. In fact, it can probably be
> used to attack DH, though I haven't tried to verify this. That,
> however, leaves a LOT of forms of cryptography for which it provides
> absolutely NO use whatsoever -- your normal run-of-the-mill symmetric
> block cipher is no more affected by the speed of a quantum computer
> than it is by the speed of a jet airplane. It's barely possible that
> some of the (mostly speculative) attacks involving pre-computing keys
> and looking them up could be improved a bit by the database lookup
> algorithms you can implement on a quantum computer, but I'm not at all
> sure this would be at all useful, and in any case most of them require
> more storage than exists in any case...
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
