Cryptography-Digest Digest #483, Volume #14 Thu, 31 May 01 14:13:01 EDT
Contents:
Re: National Security Nightmare? ("Sam Simpson")
Re: Question about credit card number (Mark Borgerding)
Re: Card Games ("Yoad Lustig")
Re: differential oddity ("Niels Ferguson")
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Question about credit card number (John Joseph Trammell)
Re: Medical data confidentiality on network comms ("Niels Ferguson")
Re: Quantum Computers with relation to factoring and BBS (Bob Silverman)
Re: Question about credit card number (Darren New)
Re: And the FBI, too (Re: National Security Nightmare?) (Bob Silverman)
Re: Euroean commision will recommend all citizens to use encryption in ("Thomas J.
Boschloo")
Re: Euroean commision will recommend all citizens to use encryption in ("Thomas J.
Boschloo")
Re: Certicom's ECCp-109 Challenge (call for users) (Stefan Katzenbeisser)
Re: Fractionated Morse - Help ("BenZen")
Re: Was there ever a CRM-114 Discriminator? (Sam Yorko)
Diffusion limits in block ciphers ([EMAIL PROTECTED])
Re: Definition of 'key' (John Savard)
crypt education ("Matt")
Re: Good crypto or just good enough? ("Joseph Ashwood")
----------------------------------------------------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Thu, 31 May 2001 17:06:08 +0100
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Sam Simpson wrote:
> >
> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>
> > > You shouldn't believe much of what you read in the newspaper.
> > > The NSA charter was declassified years ago. They emphatically
> > > do not have a charter to spy on US citizens; to the contrary they
> > > are forbidden by law to do so except under certain extraordinary
> > > circumstances; there are various watchdog mechanisms and mandatory
> > > awareness training in a serious attempt to conform to that law.
> >
> > True, in the same way that the UK GCHQ equivalent of doesn't spy on UK
> > citizens....It gets other countries security establishments to do their
> > dirty work.............
>
> That's not unnatural, after all.
No, but it's deceitful: The law of the country says that we can monitor Mr
x's communications, so we'll ask a foreign to spy on a UK citizen residing
in the UK to circumvent this law.
Regards,
--
Sam Simpson
http://www.scramdisk.clara.net/
------------------------------
From: [EMAIL PROTECTED] (Mark Borgerding)
Subject: Re: Question about credit card number
Date: 31 May 2001 09:13:50 -0700
Chenghuai Lu <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Most of the commecial websites keep the customers' credit card numbers
> in their database.
You sparked a thought in me.
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. i.e. After the user has added
their credit card, it gets wisked away to a more secure machine than
the webserver. This machine can only communicate to the webserver
through a well-defined interface. The webserver/database would store
only a memento (last 4,hash,etc) to identify the specific card so that
the user can select it.
The important thing is that after the credit card is initially
entered, even root on the webserver / database server cannot access
the actual card number.
The only thing it would be able to do is to purchase individual items
-- much easier to detect and defeat than the actual number being
stolen.
So the credit card server would only need to perform the following
functions:
- receive new numbers
- make purchases, given a memento from the webserver/database server
A machine that does only those functions should be much easier to lock
down and make secure than a machine that also needs to act as a
webserver.
Any comments?
------------------------------
From: "Yoad Lustig" <[EMAIL PROTECTED]>
Subject: Re: Card Games
Date: Thu, 31 May 2001 19:41:40 +0300
Hi,
I'm not sure whether your question was theoretical or practical.
If it was theoretical here's a good place to start
http://www.wisdom.weizmann.ac.il/~oded/pp.html
Nigel Smart <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
Hi All,
I am sure I once saw something about card games in a cryptographic
setting. But I cannot remember where.
Basically I would like to know is it possible for four people to
shuffle and deal 13 cards to each other
without either party knowing the cards of the other party
and
allowing each party to know that the cards have been dealt fairly
Basically this is some kind of multi-party computation but with a
shuffle.
Any pointers to the literature would be most helpful.
Yours
Nigel
--
Dr Nigel P. Smart | Phone: +44 (0)117 954 5163
Computer Science Department, | Fax: +44 (0)117 954 5208
Woodland Road, | Email: [EMAIL PROTECTED]
University of Bristol, BS8 1UB, UK | URL: http://www.cs.bris.ac.uk/~nigel/
------------------------------
From: "Niels Ferguson" <[EMAIL PROTECTED]>
Subject: Re: differential oddity
Date: Thu, 31 May 2001 18:52:44 +0200
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:j5iR6.88709$[EMAIL PROTECTED]...
[...]
> Ah notice that ciphers based on decorrelation theory (pair-wise) in
> GF(2^n)[2]/p(x) have prob 1 differentials yet don't emit a known
difference
> with prob 1. I am just seeing if there is a connection here... i.e prob 1
> differentials don't have to be a bad thing.
If you have any prob. 1 differential, then the cipher is easy to
distinguish from a random cipher. Even if there is only a single prob.
1 differential, and you don't know what the input difference is, you
can still find it using a collision search. Here is how:
We'll write a plaintext as a pair of values. Suppose the input
difference (a,b) has a prob. 1 differential to output difference
(c,d). We request the encryption of all plaintexts of the form (X,0),
(X,1), and (0,Y) for all possible values of X and Y. Note that the
plaintexts (X,0) and (0,Y) have difference (a,b) for X=a and Y=b, and
that (X,1) and (0,Y \xor 1) also have difference (a,b). In other
words, we expect to have one set of values for X and Y for which
E(X,0) \xor E(0,Y) = (c,d) = E(X,1) \xor E(0,Y \xor 1). Rearrange this
a bit and we get
E( X,0 ) \xor E( X,1 ) = E( 0,Y ) \xor E( 0, Y \xor 1)
We compute the left side of this equation for all X values, and the
right side for all Y values, and use a hash table to find all pairs
(X,Y) that satisfy this equation. On average we will find one or two
values, from which we can find (a,b) and (c,d) with a few more tries.
All in all this allows us to distinguish the cipher from a random one
using around 3*2^{n/2} steps where n is the block size.
You have to be a bit careful with decorrelation theory. It protects
against differential attacks only in a very limited setting. Given a
differential S->T it ensures that this differential has a low
probability taken over all possible keys. However, this does not limit
the probability of a differential for any particular key. The
decorrelation function used in DFC was basically
f(x) = ax + b
where a and b are part of the key. If you look at any fixed
differential S->T then this has a low probability averaged over all
keys. But for every key there are very high probability differentials.
In the attack I mentioned above the differential that you are looking
for is not specified beforehand. It can be key-dependent. In that case
the decorrelation function does not help.
Cheers!
Niels
======================================
Niels Ferguson, cryptography consultant. email: niels at ferguson dot net.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Thu, 31 May 2001 07:58:24 -0800
"SCOTT19U.ZIP_GUY" wrote:
> bit in a file. When one compresses and exaimes the results for
> testing all the possible keys. The number of valid look messages
> increase. This increase in the number of message means one needs
> to look at longer and long sequences to reject the large number
> of message. Shannon was the one to prove this second effect out
> weight the first so that compression is good.
Where does Shannon discuss compression in detail? I did a quick flip
through
his "Comm. Theory of Secrecy Systems" and only found a passing reference
to
compression. If memory serves, he doesn't discuss it in "A Mathematical
Theory of Comm. Systems" either.
I would be interested in reading any research he did on compression.
As far as I'm concerned, Shannon was "the man" (and not just because
of his secrecy system theory).
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: Question about credit card number
Date: Thu, 31 May 2001 17:00:02 GMT
On 31 May 2001 09:13:50 -0700, Mark Borgerding <[EMAIL PROTECTED]> wrote:
> Chenghuai Lu <[EMAIL PROTECTED]> wrote in message
>news:<[EMAIL PROTECTED]>...
> > Most of the commecial websites keep the customers' credit card numbers
> > in their database.
>
> You sparked a thought in me.
>
> 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. i.e. After the user has added
> their credit card, it gets wisked away to a more secure machine than
> the webserver. This machine can only communicate to the webserver
> through a well-defined interface. The webserver/database would store
> only a memento (last 4,hash,etc) to identify the specific card so that
> the user can select it.
Sounds interesting -- what would one use as the memento? Last 4 +
name + expiry?
> The important thing is that after the credit card is initially
> entered, even root on the webserver / database server cannot access
> the actual card number.
> The only thing it would be able to do is to purchase individual items
> -- much easier to detect and defeat than the actual number being
> stolen.
It would have to be able to go through the whole credit card
auth/settle/refund procedure, but sure.
+-------+ +---------+ +--------+ +----------+
| buyer +<-->+ website +<-->+ daemon +<-->+ cc agent |
+-------+ +---------+ +--------+ +----------+
>
> So the credit card server would only need to perform the following
> functions:
> - receive new numbers
> - make purchases, given a memento from the webserver/database server
>
> A machine that does only those functions should be much easier to lock
> down and make secure than a machine that also needs to act as a
> webserver.
>
> Any comments?
What would the protocol between "website" & "daemon" look like?
------------------------------
From: "Niels Ferguson" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Thu, 31 May 2001 19:03:07 +0200
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9f55r3$2ffu$[EMAIL PROTECTED]...
> Medical privacy has a radically different set of problems from military
> security.
I agree completely. There are real problems with restricting access to
medical data, as there are always situations in which somebody needs
access right now.
Many problems can be solved by having a system in which people have
access, but _every_ access is reported to the patient in question. This
requires some low-level authentication to know who was accessing the
data. It is probably good enough to stop most of the abuse. Certainly
in the US with its class-action lawsuits a tracking system would deter
systematic illegal use of medical data. If the abuse of the data is legal,
you don't need a technical solution but a political one.
Cheers!
Niels
--
======================================
Niels Ferguson, cryptography consultant. email: niels at ferguson dot net.
------------------------------
From: [EMAIL PROTECTED] (Bob Silverman)
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: 31 May 2001 10:10:59 -0700
[EMAIL PROTECTED] (Bill Unruh) wrote in message
news:<9eu1ke$njh$[EMAIL PROTECTED]>...
> In <9etv2h$4pn$[EMAIL PROTECTED]> "Scott Fluhrer" <[EMAIL PROTECTED]>
>writes:
> ]>
> ]> 1. Do we know factoring is NP for certain?
<snip>
>
> But asking "is a problem NP" is usually a shorthand for
> "Is the problem NP but not P".
Since when??? It most certainly is NOT such a shorthand. "Is a problem
in NP?" is a well-defined, unambiguous question.
> Factoring is probably NOT NP complete. But it is probably also not in P
The fact that we have a sub-exponential time algorithm is evidence for the
first statement. However, we have no evidence for the latter except our
own ignorance.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Question about credit card number
Date: Thu, 31 May 2001 17:11:33 GMT
Mark Borgerding wrote:
> A machine that does only those functions should be much easier to lock
> down and make secure than a machine that also needs to act as a
> webserver.
Yes. It works fine. Indeed, in the system I worked on (the First Virtual
system), the credit cards never went over the net. You got a single-use
code number via email. You dialed up our 800 number, typed in your code
number and credit card number into the touchpad, and you were set. The
"above the line" system never saw the credit card number even once,
since it never went over the internet at all.
Of course, much of this was obsoleted by the widespread deployment of
the web and SSL. Our system was driven by either the web or via email,
since at the time of deployment, compuserve and AOL weren't allowing web
access to the internet.
The "below the line" system would periodically call out to "above the
line" to get the list of confirmed charges to be charged against the
card, and to return the information about whether the charge was honored
and such. A single wire, a very restricted protocol, and no internet
connectivity on the "below the line" system. You actually had to go into
a guarded room to get to the machine with the CC#s, and that room held
the machines for clearing the charges, too. If you got past the physical
security, there were much more tempting targets than *our* toys. ;-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
This is top-quality raw fish, the Rolls-Rice of Sushi!
------------------------------
From: [EMAIL PROTECTED] (Bob Silverman)
Crossposted-To: talk.politics.crypto,us.misc
Subject: Re: And the FBI, too (Re: National Security Nightmare?)
Date: 31 May 2001 10:15:47 -0700
Matthew Montchalin <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Wed, 30 May 2001, Sam Yorko wrote:
> |I guess what I really meant is if someone confronted me with an NSA
> |badge, how in the world could I verify this?
Call Ft. Meade. You will be connected to an operator there. He/She
will ask you for a name. If the person is an employee, you will be
connected.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in
Date: Thu, 31 May 2001 19:09:43 +0200
John Savard wrote:
> And yet there was a recent news item that said Holland was planning to
> follow the same path as Britain with its R.I.P. bill.
Only for TTP (trusted third parties).
We already do have the kind of 'black-boxes' RIP envisions, but
implementation is up to the providers themselves (as they are also the
ones who will have to pay for it). This is the law now, but most
providers are not ready for police tap demands yet. (So allright, it is
not exactly like RIP and not exactly a 'black' box)
Thomas
--
Android 16: "I will only fight Goku"
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in
Date: Thu, 31 May 2001 19:17:13 +0200
Mok-Kong Shen wrote:
> France had a very restictive crypto law. But that has
> been discarded (presumably due to the Echelon affairs), or
> am I ill-informed in that?
<http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm> used to be pretty
accurate. I am surpised the people here didn't bring up that link. It is
well known in groups like alt.privacy.pgp I recon.
<http://www2.epic.org/reports/crypto2000/countries.html#Heading87> is
also cool (if that is the right link from my bookmarks). Countries are
rated crypto-friendly from Green, Yellow to Red with also mixtures of
those colors.
Thomas
--
Android 16: "I will only fight Goku"
------------------------------
Date: Thu, 31 May 2001 19:28:33 +0200
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: Certicom's ECCp-109 Challenge (call for users)
Chris Monico wrote:
> The x86 ports of the software are heavily optimized, with assembly
> functions to do arithmetic modulo 'p'. While there is non-assembly
> arithmetic included so that the code will compile on many 32-bit
> machines with gcc, it is considerably slower without an assembly routine
> for doing modular multiplication in Z/(pZ). There is currently no 64-bit
> support at all.
Do you plan to include support for 64 bit platforms soon? I have access to some
Linux/Alpha machines that are idle almost all the time... Remember that in the
last Certicom challenge Alphas were the fastest machines and contributed a
large portion of points!
-S
------------------------------
From: "BenZen" <[EMAIL PROTECTED]>
Subject: Re: Fractionated Morse - Help
Date: Thu, 31 May 2001 13:35:33 -0400
John Savard wrote in message <[EMAIL PROTECTED]>...
>On 28 May 2001 12:53:26 -0700, [EMAIL PROTECTED] (Charles
>Eastwood) wrote, in part:
>
>>Can anyone point me to references on breaking fractionated Morse
>>messages?
>
>>I think there are at least two types. In one the Morse string,
>>including "X" for letter breaks, is divided into groups of three
>>characters. A table is then used to turn each group into one letter of
>>the CT. In the other system a string of numbers is formed based on
>>the number of dots and dashes in each letter. That string of numbers
>>is transposed, and then used to generate a new Morse string which is
>>then converted to letters.
>
>>I am interested in attacks on both systems.
>
>Well, the book "Cryptanalysis for Microcomputers" from TAB Books talks
>about the first system. The second system is discussed in Gaines, and
>since as illustrated the only key is the length of the group over
>which the lengths are reversed, it can be solved by brute force by
>hand.
>
>Both systems are described on my web site, but their cryptanalysis is
>not discussed.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/frhome.htm
John..... You never cease to amaze me. :D
I was doing a quick research of various compression techniques,
and upon browsing a few links about Huffman, I found this:
http://home.ecn.ab.ca/~jsavard/crypto/mi060307.htm
Which is about Huffman, applied to Morse...Related topic here.
That link came from the FAQ on compression: part-1
http://www.faqs.org/faqs/compression-faq/part1/
Regards,
And God's speed !!!
A new fan of yours,
Ben
------------------------------
From: Sam Yorko <[EMAIL PROTECTED]>
Subject: Re: Was there ever a CRM-114 Discriminator?
Date: Thu, 31 May 2001 10:42:24 -0800
John Savard wrote:
>
> On Tue, 27 Feb 2001 20:33:23 GMT, [EMAIL PROTECTED]
> (John Savard) wrote, in part:
> >On Tue, 27 Feb 2001 14:26:07 -0600, Ed Kubaitis <[EMAIL PROTECTED]> wrote,
> >in part:
>
> >>On another front, just came across this information just suggesting
> >>that CRM-114 was a continuing motif in Kubrick movies:
>
> >> http://www.eeggs.com/items/1589.html
>
> >Like THX-1138 with George Lucas...
>
> In addition to the license plate on a car in the movie American
> Graffiti, could it have been the actual number on the license plate of
> a car *owned* by George Lucas? And could CRM-114 have similarly
> appeared on the license plate of a car owned by Stanley Kubrick?
>
> In fact, I have a suspicion that I may have decoded why these men
> might have each found their first cars to be such an intensely
> emotional experience...
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
No for George Lucas; when he was growing up, CA license plates were
three letters, three numbers. He >might< have had THX-138, but then
where did the extra 1 come from?
Sam
------------------------------
From: [EMAIL PROTECTED]
Subject: Diffusion limits in block ciphers
Date: Thu, 31 May 2001 08:45:56 -0800
For an n-bit block cipher, plaintext bits 0 through n-1 can only affect
ciphertext bits 0 through n-1. Input changes in one block have
absolutely
no effect on the outputs of other blocks. From a theoretical point of
view, this appears to be a bad thing.
Instead of having one big well-mixed lump of dough we have many smaller
well-mixed (hopefully) lumps of dough placed side by side. Consequently,
instead of attacking a big lump, the cryptanalyst can attack a small
lump.
I haven't thought this through thoroughly, but it seems that diffusion
could be improved using conventional Feistel network block ciphers by
doing a small number of rounds on several blocks and then permutating
the results (exchange the intermediate outputs of one block with the
intermediate outputs of another block) before doing
another small number of rounds and then permutating between blocks
again.
As long as the inter-block permutations can be reversed for decryption,
and as long as the inputs to the F functions can be replicated for
decryption, I'm pretty sure that this multiple Feistel network would
still be reversible and it would spread the diffusion among several
blocks.
It shouldn't significantly increase encryption time but it would
increase
memory requirements and possibly error propagation.
I'd like to hear comments on this, primarily on block cipher diffusion
limits. Several times in this newgroup people have said, "block ciphers
are a solved problem" so my guess is that limited diffusion really isn't
a big issue. Wouldn't interaction between blocks be a good thing?
=====BEGIN PGP MESSAGE=====
Version: PGP 6.5.8
owEBUACv/4kAPwMFADr8zeJeh8Vpi2BPfBECIdMAnj2JL4t7ldNTP6AdJpgPZfcJ
CyCJAJwOZpDqGOriihtsout3jjUnUCSpN6wMYgZwZ3BzaWcVAAAA
=dADa
=====END PGP MESSAGE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Definition of 'key'
Date: Thu, 31 May 2001 17:49:09 GMT
On 31 May 2001 04:37:01 -0700, [EMAIL PROTECTED] (Patrick Aland)
wrote, in part:
>I was talking to someone today and we were trying to come up with a
>good formal definition of a key (in regards to cryptography, no
>car/house/etc key comments please :) )
>Now after looking through the few crypto books I have (Applied crypto,
>etc) they don't seem to have a good definition either.
>Can anyone help me out?
A cipher is a set of transformations, which when applied to a
plaintext, produce a ciphertext. The key is the number of a
transformation in that set.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Matt" <[EMAIL PROTECTED]>
Subject: crypt education
Date: Thu, 31 May 2001 11:05:36 -0700
Greetings, all,
I'm considering go back to college for a double major in computer science
and mathematics. I've had a lot of schooling, but never finished a degree.
I'm very interested in cryptography and security and am looking for
recommendations on what types of classes will best help me understand the
field. The math I've already had included calculus, differential equations,
math modeling, statistics, and systems engineering of the
queueing/least-path/cpm type. My computer experience includes some
programming I've picked up on my own and network administration work.
I appreciate any comments and hope this is an appropriate topic for this
group.
Thanks,
Matt
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Thu, 31 May 2001 11:01:43 -0700
I have little doubt that I missed something in my proof, in fact I think it
can be simplified by eliminating the first case, and stating the
independence of the keys, giving the odds of a collision to fall into what
is right now the first category the same odds that the adversary has of
guessing the key on the first try. Regardless as long as we agree that it is
provable somehow that 3DES is at least as secure as DES my lack of ability
to prove it in 30 seconds matters little.
Joe
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9f4lut$26gg$[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> >Well then let me change it a bit. We have two cases, the first case is
where
> >the first and second key are the same, the result is straight DES.
> >
> >The second case is where the first and second key are different, this
> >results in a construct of the form DES followed by something. If that
> >something weakened DES the something could be applied by an adversary, so
> >DES can be no stronger than 3DES.
> >
> >Those are complete cases, and in both cases it was proven that DES cannot
be
> >stronger than 3DES. Therefore 3DES must be at least as strong as DES.
>
> Your conclusion is valid, but your proof technique is, I think, not.
> Consider the following `proof' that 3DES no more secure than DES:
> Let K1,K2,K3 be the DES keys used in 3DES. There are 2^112
> cases for the value of K2,K3 (0,0; 0,1; 0,2; and so on). In
> each case, one can decrypt by K3, then by K2, to get a ciphertext
> for DES. Therefore, in every possible case, 3DES is no more secure
> than DES. Therefore, 3DES must be no more secure than DES.
> Obviously this proof is incorrect, and the reason is that the adversary
> can't tell which case he is in.
------------------------------
** 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
******************************
