Cryptography-Digest Digest #493, Volume #14 Fri, 1 Jun 01 23:13:01 EDT
Contents:
Re: And the FBI, too (Re: National Security Nightmare?) (David Schwartz)
Re: Is RSA suitable for DSA? ("Tom St Denis")
Re: And the FBI, too (Re: National Security Nightmare?) ("Tom St Denis")
Re: Visit "Frog's" Place ("Paul Pires")
Re: Medical data confidentiality on network comms (wtshaw)
Looking for on-line copies of the original papers. (Ed Pugh)
Re: Looking for on-line copies of the original papers. ("Tom St Denis")
Re: Question about credit card number (Chenghuai Lu)
Re: Question about credit card number (those who know me have no need of my name)
Re: Chinese Remainder Theorem Confusion ... Please Help (Nicol So)
Re: Looking for on-line copies of the original papers. (Paul Rubin)
Re: And the FBI, too (Re: National Security Nightmare?) (those who know me have no
need of my name)
Re: Cookie encryption (those who know me have no need of my name)
Re: Question about credit card number ("Jeffrey Walton")
Re: Uniciyt distance and compression for AES (Dennis Ritchie)
Re: Question about credit card number (Chenghuai Lu)
Re: Question about credit card number ("Tom St Denis")
Re: Question about credit card number ("Jeffrey Walton")
Re: Diffusion limits in block ciphers ("Scott Fluhrer")
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: And the FBI, too (Re: National Security Nightmare?)
Date: Fri, 01 Jun 2001 16:01:45 -0700
David Schwartz wrote:
> In my experience, NSA people aren't too keen about exposing themselves
> as such outside of DoD facilities.
By the way, I'm talking about civilians employed by the NSA, not
officers or enlisted personnel assigned to NSA divisions. They seem to
be less diligent about putting their badges away before they walk into,
say, a Burger King.
DS
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is RSA suitable for DSA?
Date: Fri, 01 Jun 2001 23:15:49 GMT
"Uros Podlogar" <[EMAIL PROTECTED]> wrote in message
news:9f7skj$3v6$[EMAIL PROTECTED]...
> here is how I think:
>
> 1. I would like to generate registration code that are relatively easy to
> check and hard to generate.
This is easy. [*]
> 2. Code checking algorithm should not reveal code generating algorithm.
This is easy. [*]
> 3. The only solution that I can think of right now is RSA. Private key is
> not revealed and hard to find. Public key could be inside my registration
> code checking algorithm and with simple reverse engineering, private key
> could not found.
This is not a solution. Obviously you are new to crypto so I will try to be
nice.
A solution is something that not only fills aesthetic needs but actually
prevents the unwanted attackers. So what if I can't fake a registration.
If I can simply remove the check code from the executable I don't need to.
> The problem is if I use long public and private key, I would also get long
> registration code. It is not appropriate to send registration string 500
> bytes long. Because of that I would like to know if I have any other
option.
Actually you have more problems then just that.
Tom
[*] I mean in the sense that it can be accomplished relatively easily with
todays academia.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: And the FBI, too (Re: National Security Nightmare?)
Date: Fri, 01 Jun 2001 23:16:33 GMT
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> David Schwartz wrote:
>
> > In my experience, NSA people aren't too keen about exposing
themselves
> > as such outside of DoD facilities.
>
> By the way, I'm talking about civilians employed by the NSA, not
> officers or enlisted personnel assigned to NSA divisions. They seem to
> be less diligent about putting their badges away before they walk into,
> say, a Burger King.
Why are you guys discussing this in sci.crypt.
I know I am not the king of the castle here but seriously people.... this is
way off topic.
Tom
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Visit "Frog's" Place
Date: Fri, 1 Jun 2001 16:16:22 -0700
Joseph Ashwood <[EMAIL PROTECTED]> wrote in message news:uxp9qyt6AHA.261@cpmsnbbsa09...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message news:2qSR6.3630
> > "Frog20000" <[EMAIL PROTECTED]> wrote in message
> > > http://welcome.to/speech.....
> > And the reason you posted this link is [________________________________]?
> Because he's under the delusion that he has created a cipher worth posting a
> link to it here repeatedly in the hopes that someone will eventually take
> notice, fail to recognise that it is weak and scream it's security from the
> highest mountain.
> Joe
Slim & none and Slim left town.
More likely and far more useful would be that a
flaw would be found and commented on where
he could get some positive value from the experience
if, and it's a big if, he was capable of profiting from
the experience. More likely than the zero chance outcome
above but still a feeble hope in absolute terms.
If it were a good algorithm, he'd be posting it in the hopes that
someone would notice it, recognize that it wasn't obviously,
trivially flawed and comment anyway out of curiosity or
interest. We're back to Slim & none.
A far less likely outcome.
If any useful result is porportionate to the degree of
"obvious useless-ness" Why bother?
Paul
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Fri, 01 Jun 2001 17:02:48 -0600
In article <9f8kmp$2hdc$[EMAIL PROTECTED]>, "Harris Georgiou"
<[EMAIL PROTECTED]> wrote:
> So true!
> Would anyone propose Microsoft to develop software for ER support units?
> And if plug-n-play wouldn't work quite well with the new drivers, the
> unconsious patient would have been pleased to know that due to an
> unrecoverrable general protection fault at address XXXX:0000FF the unit
> needs to be rebooted?....
> No wonder why they call them "blue screens of death"....
>
MS Law of Creative Artifical Intelligence: Every system must prematurely
die or suffer from an illness that will be blamed on the user.
I'm about to visit Turnerville...can we still say that? If addition to
other plans, I'm hoping that Bobbie's LIVE show in on some topic that I
can relate too. The
odds that it will be about crypto per se are pretty low, but I'll see if I
can work it in anyway. Maybe I'll just be quiet; those odds are also in
the low probability range. Oh well...on the road again. You have to stir
up the ducks before it is sporting to wing them.
--
Sign for the White House lawn:
WARNING! Irresponsible Parents Live Here.
------------------------------
From: [EMAIL PROTECTED] (Ed Pugh)
Subject: Looking for on-line copies of the original papers.
Date: 2 Jun 2001 00:33:43 GMT
Reply-To: [EMAIL PROTECTED] (Ed Pugh)
Hi, all.
This is probably a FAQ (and if it is answered somewhere,
please show me where), but ...
where can I find on-line, downloadable copies (perhaps in
PDF format, or something similar) of the two original
papers that started the PKC ball rolling.
Specifically, I would like to read "New Directions in
Cryptography" by Diffie and Hellman, and the MIT
Technical Memo number 82 (don't know the actual title)
by Rivest, Shamir and Adleman. (This is the paper
that got mass mailed out to the respondents of the
Martin Gardner column in Sci. Am.)
I will look for follow-ups here.
Thanks and regards,
--
Ed Pugh | "A common mistake that people make when trying
Ottawa (Richmond) | to design something completely foolproof, is to
Ontario, Canada | underestimate the ingenuity of complete fools."
| - Douglas Noel Adams, 1952 - 2001 :-(
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Looking for on-line copies of the original papers.
Date: Sat, 02 Jun 2001 01:12:38 GMT
"Ed Pugh" <[EMAIL PROTECTED]> wrote in message
news:9f9c97$rv7$[EMAIL PROTECTED]...
>
> Hi, all.
>
> This is probably a FAQ (and if it is answered somewhere,
> please show me where), but ...
>
> where can I find on-line, downloadable copies (perhaps in
> PDF format, or something similar) of the two original
> papers that started the PKC ball rolling.
>
> Specifically, I would like to read "New Directions in
> Cryptography" by Diffie and Hellman, and the MIT
> Technical Memo number 82 (don't know the actual title)
> by Rivest, Shamir and Adleman. (This is the paper
> that got mass mailed out to the respondents of the
> Martin Gardner column in Sci. Am.)
>
> I will look for follow-ups here.
RSA paper at
http://tomstdenis.home.dhs.org/rsapaper.zip
Tom
------------------------------
From: Chenghuai Lu <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Fri, 01 Jun 2001 21:18:00 -0400
John Hairell wrote:
>
> On Fri, 01 Jun 2001 13:56:16 GMT, [EMAIL PROTECTED] (Roger Fleming)
> wrote:
>
> Actually, a whole bunch of commercial websites have been hacked,
> including some large ones, based on the fact that the front ends used
> encryption but the back ends were somewhow left open, and the CC
> numbers were not stored in an encrypted form. Many of the hacks were
> based on systems people not keeping their systems patches up to date,
> and ignoring information about well-known attacks.
Even if the CC numbers are stored in an encrypted form in the back ends,
they are easy to break since all of CC numbers are encrypted using the
same master key. Isn't it right?
--
-Chenghuai Lu ([EMAIL PROTECTED])
------------------------------
From: those who know me have no need of my name <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: 02 Jun 2001 01:11:48 GMT
<[EMAIL PROTECTED]> divulged:
>I imagine most web credit card systems store the number in a database
>that is accessible to the webserver.
>
>Instead, wouldn't it be better to give the webserver very limited
>capability to use the credit card.
smart ones do it as you suggest, making only stored procedures (or
custom views) available to the web server, usually through a firewall
that can inspect the traffic to prevent deviation.
mementos are used by most wallets of which i am aware.
preventing a dba from accessing the data is more difficult, but not
impossible.
preventing root is usually not possible, except on o/s' specially
written for security compartmentalization, which usually makes running
the database pretty hairy as well.
--
okay, have a sig then
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Chinese Remainder Theorem Confusion ... Please Help
Date: Fri, 01 Jun 2001 22:06:26 -0400
Reply-To: see.signature
[EMAIL PROTECTED] wrote:
>
> Hi All,
>
> can someone please explain the following to me (what am I missing here)? Sorry
> if the other details are sparse, but hopefully they do not matter. Note: this
> is from ANSI X9.31.
>
> Step 3: Apply the Chinese Remainder Theorem (twice) to compute:
>
> R1 = (b^-1 mod a)b - (a^-1 mod b)a. Let ya = xp + (r1 - xp mod ab).
> ya is now the first integer greater than xp such that a is a large prime factor
> of ya -1 and b is a large prime factor of ya + 1.
>
> R2 = (d^-1 mod c)d - (c^-1 mod d)c. Let yb = xp + (r1 - xp mod ab).
> yb is now the first integer greater than xp such that a is a large prime factor
> of yb -1 and b is a large prime factor of yb + 1.
>
> My question is this, what does apply the CRT mean here? I have an explicit
> formula for calculating all of the parameters needed. I can use modular
> inverses for the mod functions and the rest is strightforward calculation.
>
> What am I missing in this statement? What is CRT even needed for? Any ideas?
Applying the Chinese Remainder Theorem is one way of deriving the
formulas for ya and yb (and also a good way to see why the formulas
yield numbers with the desired properties). In other words, the formulas
themselves embody an application of CRT.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Looking for on-line copies of the original papers.
Date: 01 Jun 2001 19:11:07 -0700
[EMAIL PROTECTED] (Ed Pugh) writes:
> Specifically, I would like to read "New Directions in
> Cryptography" by Diffie and Hellman, and the MIT
> Technical Memo number 82 (don't know the actual title)
> by Rivest, Shamir and Adleman. (This is the paper
> that got mass mailed out to the respondents of the
> Martin Gardner column in Sci. Am.)
I haven't seen the DH paper online, but it's in the IEEE Press
collection "Contemporary Cryptology" edited by Gus Simmons.
------------------------------
From: those who know me have no need of my name <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: And the FBI, too (Re: National Security Nightmare?)
Date: 02 Jun 2001 01:20:01 GMT
<lnVR6.4778$[EMAIL PROTECTED]> divulged:
>Why are you guys discussing this in sci.crypt.
>
>I know I am not the king of the castle here but seriously people.... this is
>way off topic.
as are business ethics in s.c, though it is perhaps on-topic in t.p.c.
likewise how-to use pgp is off-topic in both groups.
as long as it doesn't go on too long it hardly matters. invoke your
killfill (or scoring or whatever) and move on with your life.
--
okay, have a sig then
------------------------------
From: those who know me have no need of my name <[EMAIL PROTECTED]>
Subject: Re: Cookie encryption
Date: 02 Jun 2001 01:24:51 GMT
<[EMAIL PROTECTED]> divulged:
>But, according to RFC cookie specification, cookie cannot store
>sensitive data like credit card number, password. So, people can say,
>the Etrade example is because of its bad implementation, not the need of
>encryption for cookies.
a) just because a specification says that something should not be
done, or even may not be done, does not actually prevent the web
site from doing it.
b) even if the cookie does not store your account number or password
the fact that it can be used to cause the web server to perform
actions on your account is why it must be strong.
--
okay, have a sig then
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Fri, 1 Jun 2001 22:38:10 -0400
: Even if the CC numbers are stored in an encrypted form in the back
ends,
: they are easy to break since all of CC numbers are encrypted using the
: same master key. Isn't it right?
Lu, you can claim the prizes now...
http://www.rsasecurity.com/rsalabs/challenges/factoring/index.html
:)
They could also be encrypted with symmetric keys, which is basically
just as hard. For example, a symmetric key with length x is
approximately as secure an asymmetric key length of y.
Jeff
"Chenghuai Lu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: John Hairell wrote:
: >
: > On Fri, 01 Jun 2001 13:56:16 GMT, [EMAIL PROTECTED] (Roger Fleming)
: > wrote:
: >
: > Actually, a whole bunch of commercial websites have been hacked,
: > including some large ones, based on the fact that the front ends
used
: > encryption but the back ends were somewhow left open, and the CC
: > numbers were not stored in an encrypted form. Many of the hacks
were
: > based on systems people not keeping their systems patches up to
date,
: > and ignoring information about well-known attacks.
:
: Even if the CC numbers are stored in an encrypted form in the back
ends,
: they are easy to break since all of CC numbers are encrypted using the
: same master key. Isn't it right?
:
:
: --
:
: -Chenghuai Lu ([EMAIL PROTECTED])
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 02 Jun 2001 02:48:41 +0000
[EMAIL PROTECTED] wrote:
>
> I think I will order that [Shannon Collected Papers book] (although
> I may have to save my lunch money
> for a month to pay for it). BTW, are you "the" Dennis Ritchie (as in
> one of "the men")? ;)
As Gwyn pointed out, an alternative is locating a library copy,
though I suppose it would have to be a fairly good library.
Nevertheless it is a neat book--Shannon had a very broad career,
and so his papers on chess programs, his mouse-in-maze machine,
and even juggling are all there.
re BTW--well, all indications are that I have exactly one X and one Y
chromosome in most cells, so..., but there are other Dennis Ritchies:
http://www.cs.bell-labs.com/~dmr/otherlives.html
Dennis
------------------------------
From: Chenghuai Lu <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Fri, 01 Jun 2001 22:46:53 -0400
Jeffrey Walton wrote:
>
> : Even if the CC numbers are stored in an encrypted form in the back
> ends,
> : they are easy to break since all of CC numbers are encrypted using the
> : same master key. Isn't it right?
>
> Lu, you can claim the prizes now...
>
> http://www.rsasecurity.com/rsalabs/challenges/factoring/index.html
>
> :)
>
> They could also be encrypted with symmetric keys, which is basically
> just as hard. For example, a symmetric key with length x is
> approximately as secure an asymmetric key length of y.
>
> Jeff
>
Decrypting the CC numbers just based on the ciphertext is certainly
hard. But isn't the safe storage of the master key a problem? Since the
cryption always use the master key, the master key will become the
target of hackers.
--
-Chenghuai Lu ([EMAIL PROTECTED])
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Sat, 02 Jun 2001 02:53:35 GMT
"Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
news:3b1850bd$0$[EMAIL PROTECTED]...
> : Even if the CC numbers are stored in an encrypted form in the back
> ends,
> : they are easy to break since all of CC numbers are encrypted using the
> : same master key. Isn't it right?
>
> Lu, you can claim the prizes now...
>
> http://www.rsasecurity.com/rsalabs/challenges/factoring/index.html
>
> :)
>
> They could also be encrypted with symmetric keys, which is basically
> just as hard. For example, a symmetric key with length x is
> approximately as secure an asymmetric key length of y.
What the heck does that mean? asymmetric ciphers solve different problems
then symmetric ones.
That's like saying y grams of potassium is approximately as good as x grams
of sodium.
Tom
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Fri, 1 Jun 2001 22:59:01 -0400
O.K. Sorry about that.
: Since the cryption always use the master key, the
: master key will become the target of hackers.
Seems like a fair assumption. I probably would bet against it.
Jeff
"Chenghuai Lu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: Jeffrey Walton wrote:
: >
: > : Even if the CC numbers are stored in an encrypted form in the back
: > ends,
: > : they are easy to break since all of CC numbers are encrypted using
the
: > : same master key. Isn't it right?
: >
: > Lu, you can claim the prizes now...
: >
: > http://www.rsasecurity.com/rsalabs/challenges/factoring/index.html
: >
: > :)
: >
: > They could also be encrypted with symmetric keys, which is basically
: > just as hard. For example, a symmetric key with length x is
: > approximately as secure an asymmetric key length of y.
: >
: > Jeff
: >
:
: Decrypting the CC numbers just based on the ciphertext is certainly
: hard. But isn't the safe storage of the master key a problem? Since
the
: cryption always use the master key, the master key will become the
: target of hackers.
:
:
: --
:
: -Chenghuai Lu ([EMAIL PROTECTED])
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Diffusion limits in block ciphers
Date: Fri, 1 Jun 2001 19:55:04 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> [EMAIL PROTECTED] wrote:
> >
> [snip]
> > What I meant by the latter sentence is that a block cipher operates
> > only on a n-bit portion of the entire message, so the diffusion only
> > occurs within those n-bits. Apparently this isn't a problem but
> > I don't understand why. Intuitively it seems that a hypothetical
> > block cipher with a block length, N, equal to the entire message length
> > would have better strength than using the same block cipher algorithm to
> > encrypt
> > the message in n bit chunks where n<<N.
>
> In general, having a larger block size should 'permit'
> better encryption, I believe. (Analogy: In optimization,
> posing constraints generally reduces the optimum.) Thus
> whole file processing, which is the extreme case, should
> be advantageous, if done right. (There are certainly
> people who claim that it is difficult to do right in
> that, though, and conclude that the currently common
> block sizes are the best ones.)
You are correct, everything being equal, larger blocks are better than
smaller ones. However, no matter what you diffuse the information over, the
diffusion really must be complete -- any partial diffusion [1] can give the
attacker clues about what the last few rounds look like, and that's a Very
Bad Thing. And, as the size of the block grows, it tends to get
increasingly difficult to maintain the amount of diffusion (without also
increasing the amount of time spent per bit encrypting), and hence in
practice, we tend to arrive at a compromise, where the block size is big
enough that we don't get problems from it being too small, and not much
bigger than that.
[1] And, by diffusion, I am talking about something more general than simply
SAC -- there should be no way the effect a change in the input on the output
can be expressed in a simple (and nontrivial) manner.
--
poncho
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
