Cryptography-Digest Digest #992, Volume #10 Fri, 28 Jan 00 02:13:01 EST
Contents:
Re: Why did SkipJack fail? (Paul Rubin)
Re: WW2 Cypher Yet Unbroken ... ([EMAIL PROTECTED])
Re: ECC & RSA re: patents, copyrights (Jane A. Gilbert)
Re: "Trusted" CA - Oxymoron? (Anne & Lynn Wheeler)
designing secure backdoors into the system (Yusuf Motiwala)
Re: Any Reference on Cryptanalysis on RSA ? ("Douglas A. Gwyn")
Re: Any Reference on Cryptanalysis on RSA ? ("Joseph Ashwood")
Re: RSA BSAFE Crypto-J Question ("Joseph Ashwood")
Re: How much does it cost to share knowledge? ("Douglas A. Gwyn")
Re: NEC claims New Strongest Crypto Algor ("Douglas A. Gwyn")
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Sierchio)
Re: How much does it cost to share knowledge? ("Trevor Jackson, III")
Re: Best Encryption Software? ("Trevor Jackson, III")
Re: designing secure backdoors into the system ("Trevor Jackson, III")
Re: designing secure backdoors into the system ("Joseph Ashwood")
Re: designing secure backdoors into the system (Yusuf Motiwala)
Re: Any Reference on Cryptanalysis on RSA ? (Jerry Coffin)
Re: Why did SkipJack fail? (Jerry Coffin)
Re: Why did SkipJack fail? ("Douglas A. Gwyn")
Re: designing secure backdoors into the system ("Trevor Jackson, III")
Re: RSA BSAFE Crypto-J Question (Paul Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Why did SkipJack fail?
Date: 28 Jan 2000 05:10:39 GMT
In article <86qmo7$3dd$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>> The way to slow down brute force search is with more bits of keyspace,
>> not more complexity to the cipher.
>
>This is always the cheap way to increase security, but does it
>always work? Does DES used three times with a total key size
>of 168 bits yield the same strength of a cipher that uses a
>native key size of 168 bits, like Blowfish?
The general answer is that increasing keyspace always works if the
ciphers are good. The definition of a broken cipher (or at least
a "certificational weakness") is any cryptanalysis that's less work
than searching the key space.
The detailed answer can be complicated. For example, triple DES with
168-bit keys is not really a single cipher--it's still 56 bit DES run
three times. Because of that, it can be subject to a
meet-in-the-middle attack that that uses 2**112 operations and 2**64
blocks of memory.
Anyway, the only serious ciphers these days for which brute force
keysearch is remotely feasible are the ones that are deliberately
made weak for whatever reasons. 112 bits and 168 bits are both
about as good as infinity bits.
If you don't mind my editorializing for a minute (and this is nothing
personal), worrying about brute force cryptanalysis of properly
designed block ciphers with reasonable keyspace is a common and
generally pointless obsession of newbies. It's much more worthwhile
to worry about protocol bugs, implementation bugs, key management
lapses, and other issues which have much more frequent practical
consequence. Those represent far larger vulnerabilities than the
underlying block ciphers in just about any real-world cryptography
system.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: WW2 Cypher Yet Unbroken ...
Date: 28 Jan 2000 05:09:46 -0000
This may very well be an old, done-by-hand version of a One Time Pad.
This particular version uses a random table of 5 digit numbers which is
added to each character of a message, one letter per 5 digit number.
Here's an example:
Suppose the first number in the pad is 12345. Now, we encrypt the
letter A, which has a value of 1, by adding it to 12345, thus the
resulting ciphertext is 12346.
Now, I could be wrong and it may not be a one time pad, but it certainly
is the closest thing I've seen that produces that type of ciphertext.
Hope this helps!
csybrandy
------------------------------
From: [EMAIL PROTECTED] (Jane A. Gilbert)
Subject: Re: ECC & RSA re: patents, copyrights
Date: Fri, 28 Jan 2000 05:12:47 GMT
Reply-To: [EMAIL PROTECTED]
Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <86pv1n$rls$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Uri Blumenthal <[EMAIL PROTECTED]> wrote:
>>
>> >Jerry Coffin wrote:
>> >> Certicom has a couple of patents on specific
>> >> methods of carrying out some of the operations in ECC, but it's
>> >> entirely possible to implement ECC without using them.
>>
>> >1. I don't know for sure, but I heard that Certicom is not the
>> > only patent holder wrt. ECC.
>>
>> >2. Are you *sure* that it is entirely possible to implement
>> > ECC without using Certicom patents and still INTEROPERATE
>> > with a Certicom implementation?
>>
>> Am extremely interested in Uri's second question regarding
>> interoperability with Certicom's implementation. Can you implement
>> ECC without licensing their implementation (legally) and still be
>> interoperable?
>Yes in general, (you don't HAVE to use an ONB for example; the
>representation for the underlying field can differ, yet still yield
>the same encryption).
>However, if their implementation uses point compression you may not
>be able to interoperate without a license, since they hold a patent
>on compression.
>--
>Bob Silverman
>"You can lead a horse's ass to knowledge, but you can't make him think"
>Sent via Deja.com http://www.deja.com/
>Before you buy.
Many thanks for taking the time to respond, Bob. I appreciate the
help.
------------------------------
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 28 Jan 2000 05:15:14 GMT
[EMAIL PROTECTED] (John G. Otto) writes:
> Digicash's scheme provides both anonymity and assurance of
> the transfer. The only draw-backs WRT privacy are that they
> have a way to report the transactions and is subject to a
> traffic monitoring.
for the most part, the bank doesn't care what your DNA is ... they
just care that only the person that open/own the account & is
authorized to use the account ... is the person that uses that
account. If a CA binds a person's DNA identity in a certificate to the
public key ... it doesn't mean anything to the bank, unless the bank
has also used DNA for opening the account.
The current bank business process is to record a shared secret
... typically person's mothers maiden name when the account is opened
... and asks for that in non-face-to-face transactions.
That same business process can be upgraded to record the person's
public key. The bank then verifies digital signatures on
non-face-to-face electronic transfers/transactions with the recorded
public key ... effectively the same business process that uses mothers
maiden name to verify transactions.
No CA is required ... and no identity verification is required by 3rd
parties ... and no new business processes are required ... and no
trusted 3rd party liability is created ... and no CA policies &
practices ... current business processes just have technology
upgrades.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Yusuf Motiwala <[EMAIL PROTECTED]>
Subject: designing secure backdoors into the system
Date: Fri, 28 Jan 2000 10:51:04 +0530
Hi,
I would like to design a secure backdoor for a system so that in
imergency situation
one can access the system (for example, forgoten the password). However,
what I
would like to do is that:
- even I (designer) can not access the same backdoor without proper
information.
Hence backdoor should be dependednt on may be product serial number,
MAC
address etc.
- there should be some secure method so that admin who had once access
to the
backdoor can not use it again once he/she loose the admininistration
control over
the system for example, he/she left the job
In there any crypto technique to design such a secure backdoor. Is it
possible to have completely secure backdoor? I will appreciate any
pointers to
resources/links/publications related to designing the same.
Regards,
Yusuf
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Any Reference on Cryptanalysis on RSA ?
Date: Fri, 28 Jan 2000 05:32:37 GMT
William Hugh Murray wrote:
> Perhaps. However, I was once given a rule of thumb that said an RSA key
> had to be 8 to 10 times the number of bits to have equivalent work
> factor to a DES key. Was there no validity to that rule of thumb?
There is no validity to it.
Nobody, at least in the open community, knows for sure either of
the minimum work factors for breaking these systems under standard
conditions.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Any Reference on Cryptanalysis on RSA ?
Date: Thu, 27 Jan 2000 14:47:06 -0800
> I want to know if the "legitimate" key space of 1024 bit RSA key is more
or
> less equal to 64 bit key?
I can answer that question, I just can't answer it generically. The answer,
using the current best methods, is no. A 768-bit RSA key is approximately
equivalent to an 80-bit strong cryptography key.
New attacks on RSA, or factorization are likely to change the needed size
for the RSA key. Based on that, in order to assist in being secure for a
significant amount of time, I would recommend with going with at least a
1024 bit key, larger if you can spare the processor.
And as everyone else has said, DES is only a 56 bit key.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA BSAFE Crypto-J Question
Date: Thu, 27 Jan 2000 14:49:25 -0800
> We are currently using RSA BSAFE Crypto-J for
> Java encryption, but we did not evaluate many
> products before we purchased Crypto-J. Now that
> our license is up, we are considering changing
> products. Can anyone recommend a different
> solution?
What are your requirements? Speed? Portability (yes I know it's Java, but
Java can call native code)? Cost? Size? Algorithms?
Joe
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: Fri, 28 Jan 2000 05:39:55 GMT
Greg wrote:
> ... The Chinese don't think like Americans. ...
And they never will, at the rate they're going -- note that the
Chinese government has outlawed access to the on-line New York
Times as a controlled "state secret". The secret, of course,
is that they want their populace to believe what their leaders
tell them, instead of being able to form independent opinions
based on fact (or at least competing viewpoints) and logic.
Unfortunately, it is not just the Chinese leadership that has
that attitude.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Fri, 28 Jan 2000 05:44:32 GMT
"NFN NMI L." wrote:
> <<creates a number of fake keys in addition to the true encryption key. >>
> What?
That indeed seems to be the "new" feature of the NEC system.
It would be interesting to hear some detail about this notion.
> <<NEC says when compared to its previous technology, 1039 calculations
> would be necessary to crack the new code.>>
> Reporters never understand anything. Surely NEC isn't this stupid.
I *think* what was meant is that 10^39 (^ meaning "to the power")
times as many operations are necessary to *brute-force* the cipher.
That's around 2^129.5 which maybe is supposed to be 2^128.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Date: Thu, 27 Jan 2000 21:40:21 -0800
Sandy Harris wrote:
> Ritter and Schryver appear to have understood you completely and to have
> demolished your first two points rather thoroughly. If anyone is failing to
> understand, it seems to be you.
Precisely.
Anyone with half as much brainpower as confidence knows that these two fellows
have earned their chops and have studied the matter. I would treat an
admonishment from either of them as an act of grandmotherly kindness, and
leave it at that.
------------------------------
Date: Fri, 28 Jan 2000 00:55:46 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Greg wrote:
> > Both the Magna Carta and paper money represent quite
> > sophisticated ideas. They aren't primitive at all.
>
> Paper money, as in the federal reserve note, is
> not sophisticated.
Well, of Toynbee's 17 civilizations only the Mongolian and modern Western
Civilizations used paper money. It requires a sophisticated market to
accept a money substitute (FRN's are not money according to the U.S.
Treasury Department.)
> It is quite simply, really, because
> it is backed by nothing. They just make it seem that way
> to hide what it really is- fraud.
The fraud isn't the paper, although paper enables it, the fraud is the lack
of convertibility: Fiat Lucre.
N.B., the Mongolians had monetary inflation problems too!
------------------------------
Date: Fri, 28 Jan 2000 01:07:05 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Best Encryption Software?
Joseph Ashwood wrote:
> > Can anyone reccomend good encryption software?
> I could actually recommend several, we need more detail abvout what you want
> to do.
>
> > I need to transfer data (a database) via an FTP site and need a good
> encryption
> > program (and something that will compact it if possible). The data is
> > very sensitive so I need to feel fairly secure.
> How big is the data you need to protect? Do you need to be able to protect
> different files for different users? How fast does it need to be done?
>
> In terms of meeting the needs of many very quickly, and with little effort,
> I would recommend PGP. If you simply need it right now, and don't need
> support, just go to http://www.pgpi.org/cgi/download-wizard.cgi and download
> the version you need. Every entity that will be downloading PGP needs to
> have a copy of PGP also.
The copies of PGP can be supplied to the end users by the same mechanism their
use to receive the database. The original poster mentioned FTP, so that should
suffice for distribution. _Whatever_ encryption mechanism he uses, he'll need
to distribute the decryption mechanism in order for users to get at the
contents.
Note that there are enough dissimilar versions of PGP around that having a
reference copy with the data is a good way to reduce the demand for tech
support.
------------------------------
Date: Fri, 28 Jan 2000 01:16:10 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
Yusuf Motiwala wrote:
> Hi,
>
> I would like to design a secure backdoor for a system so that in
> imergency situation
> one can access the system (for example, forgoten the password). However,
> what I
> would like to do is that:
>
> - even I (designer) can not access the same backdoor without proper
> information.
> Hence backdoor should be dependednt on may be product serial number,
> MAC
> address etc.
> - there should be some secure method so that admin who had once access
> to the
> backdoor can not use it again once he/she loose the admininistration
> control over
> the system for example, he/she left the job
>
> In there any crypto technique to design such a secure backdoor. Is it
> possible to have completely secure backdoor? I will appreciate any
> pointers to
> resources/links/publications related to designing the same.
The idea of a completely secure back door is something of a contradiction in
terms. Why isn't a completely secure front door good enough?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
Date: Thu, 27 Jan 2000 22:17:00 -0000
Depending on your space and speed requirements, give each person an
RSA/ElGamal/ECC/SKIPJACK/etc keypair, encrypt a symmetric key a la PGP. The
keyfiles can be easily deleted/created as needed, and it carries the
potential (if done properly) to carry as much security as PGP offers. You
could as needed put any data, including passwords in the encrypted keyfiles,
and of course the only way to gain access would be to have access permission
given to you by a prior administrator, provided of course that the private
keys are kept securele off-system.
Joe
------------------------------
From: Yusuf Motiwala <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
Date: Fri, 28 Jan 2000 11:52:42 +0530
> The idea of a completely secure back door is something of a contradiction in
> terms. Why isn't a completely secure front door good enough?
The reason of backdoor is as I explained, say administrator forgoten the
password. Now he/she should be able to recover the access to the system in
consultation with
the system supplier. Now, this backdoor should be secure enough so that the
people who used the backdoor in past can not use it in future.
Infact, if any other front door solution exists for such problems, I would be
happy
to think in that direction. Any inputs?
Regards,
Yusuf
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Any Reference on Cryptanalysis on RSA ?
Date: Thu, 27 Jan 2000 23:26:15 -0700
In article <86p785$5ut$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Hi all,
>
> I want to study the relationship of the strength between the key length of
> RSA and the key length of DES.
> For example,
> Currently, 1024 bit RSA and 64 bit DES are the de facto strong key length.
DES always uses a 56-bit key. This has been broken repeatedly.
If anybody has broken RSA using a 1024-bit key, the method used was a
deep, dark secret unknown to the rest of the world.
> I want to know if the "legitimate" key space of 1024 bit RSA key is more or
> less equal to 64 bit key?
Though it's larger than a DES key, breaking a cipher using a 64-bit
key is something we can at least contemplate today -- in fact, there's
a group of people working on exactly that right now.
I suppose in a purely theoretical sense, we can contemplate breaking
RSA with a 1024-bit key. Unfortunately the "contemplation" involves
phrases like "If we could build a CPU that ran at a few hundred
gigahertz and could buy all the memory produced on earth for the next
few months, and all that memory was fast enough to more or less keep
up with the CPU then all we'd need would be..."
With that said, I think there are a couple of numbers that are worth
keeping in mind: on the RSA front, my nomination would be 1024 bits,
and on the symmetric front, 128 bits. Factoring a 1024 bit number
(unless it has a lot of small factors) or exhausting a 128-bit
keyspace is well beyond present capabilities. In both cases, I'm
applying something akin to the old engineer's rule of thumb, leaving
roughly a 20% margin of error beyond a worst-case situation. IOW,
unless there's some sort of breakthrough, 800 bits and 100 bits are
entirely adequate, but most people feel more comfortable with at least
a little "extra" padding.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Thu, 27 Jan 2000 23:26:08 -0700
In article <86p9n2$6mi$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> It's not equivalent. Making the cipher slower slows down the
> legitimate user as well as the attacker. Adding a bit to the keyspace
> only slows down the attacker.
Rather the contrary: all else being equal, you have to do more to make
use of a larger key -- you typically add more rounds or make each
round more complex.
> $250K is what the EFF web site said but anyway, $340K isn't much different
> than $500K.
I'm glad you think so -- in fact, since you think it's such a piddling
amount, you're more than welcome to pay me that much anytime you want
to... <G>
> If you want a really big speedup you have to spend megabucks.
Obviously.
> >Getting an order of magnitude (or more) chips built also gives you a
> >MUCH better bargaining position. Of course, if an representative of
> >the NSA shows up, he probably automatically has a better bargaining
> >position than a representative of the EFF in any case.
>
> The NSA has their own fabs. They wouldn't think of bringing a classified
> design to a commercial foundry.
Everything I know says they _don't_ have fabs of their own capable of
running a .18 micron process in production quantities. In any case,
there's little reason for the design to be classified here. For that
matter, it's pretty trivial for the NSA to pre-compile the files they
send to the foundry, at which point it's nearly impossible for anybody
to figure out exactly what the chip is or does.
In any case, keep in mind that foundries are _typically_ working with
designs that are worth tens of millions of dollars so even a hint that
one might leak a design to the wrong people would put the company out
of business overnight.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 06:33:58 GMT
Greg wrote:
> Well, if I were the owner of the foundry, I would feel in a better
> position to bargain if the NSA showed up- they have an almost
> unlimited supply of financing.
Hardly.
> That being said, I am quite
> certain they have their own foundry or use one that the CIA runs?!
There is a fabrication facility at Ft. Meade
run under contract by National Semiconductor,
next door to OPS3 (which incidentally was recently
designated the "Frank B. Rowlett building").
------------------------------
Date: Fri, 28 Jan 2000 02:06:46 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
Yusuf Motiwala wrote:
> > The idea of a completely secure back door is something of a contradiction in
> > terms. Why isn't a completely secure front door good enough?
>
> The reason of backdoor is as I explained, say administrator forgoten the
> password. Now he/she should be able to recover the access to the system in
> consultation with
> the system supplier. Now, this backdoor should be secure enough so that the
> people who used the backdoor in past can not use it in future.
>
> Infact, if any other front door solution exists for such problems, I would be
> happy
> to think in that direction. Any inputs?
If a forgotten/lost password is the problem, the solution is not to weaken the
system so that it can be accessed without the password, but to record the password
so it cannot be lost, and so that unauthorized persons cannot get at the recorded
copy.
Storing the password in a PGP file would work, but it requires a pass phrase, so
there's a recursion issue. If you have many passwords to save, the PGP file can
reduce the size of the problem to a single pass phrase. A sort of concentrator.
The simplest solution is physical security. Write the password down and store it
someplace like a safe or safety deposit box. Create a process by which the
authority to access the secured storage can be transferred when the personnel
change due to transfer, resignation, etc.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: RSA BSAFE Crypto-J Question
Date: 28 Jan 2000 07:01:50 GMT
In article <86peh8$4v0$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>We are currently using RSA BSAFE Crypto-J for Java encryption, but we
>did not evaluate many products before we purchased Crypto-J. Now
>that our license is up, we are considering changing products. Can
>anyone recommend a different solution?
www.openssl.org.
------------------------------
** 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
******************************
