Cryptography-Digest Digest #438, Volume #12 Mon, 14 Aug 00 11:13:00 EDT
Contents:
Re: Random Number Generator ([EMAIL PROTECTED])
Re: Random Number Generator ([EMAIL PROTECTED])
Re: Crypto Related Professional Attitude ("Trevor L. Jackson, III")
Re: New Serpent Sboxes ("Sam Simpson")
Re: Crypto Related Professional Attitude ("Trevor L. Jackson, III")
entrust software (haifeng)
Re: OTP using BBS generator? ("Trevor L. Jackson, III")
Re: Crypto Related Professional Attitude (David A Molnar)
Re: New Serpent Sboxes (tomstd)
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: Random Number Generator (tomstd)
Re: Random Number Generator ("Trevor L. Jackson, III")
Re: Random Number Generator (tomstd)
Re: Random Number Generator ([EMAIL PROTECTED])
Re: Random Number Generator (tomstd)
Re: New Serpent Sboxes ("Sam Simpson")
Re: Playfair-Analyze ? (JPeschel)
Re: Random Number Generator (Mark Wooding)
Re: OTP using BBS generator? ("Tony T. Warnock")
Re: New Serpent Sboxes (tomstd)
Re: Proposal of drafting rules of conduct of posting (JPeschel)
Re: Random Number Generator ([EMAIL PROTECTED])
Re: Random Number Generator ([EMAIL PROTECTED])
Re: Preserving confidentiality while linking data? (Baruch Even)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random Number Generator
Date: Mon, 14 Aug 2000 13:35:13 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8n0blf$4al$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > Do you think that there is no mapping of finite sets of natural
> > numbers into set of infinite sets of natural numbers?
> > Please evaluate this algorithm and you will believe.
>
> I have evaluated it. What you're claiming has long since been proven
> absolutely, positively impossible. You're several centuries behind
> the times if you think otherwise.
>
> > > > - The probability to find in random sequence 0/1
> > > > value bits is exactly 50%
> > >
> > > This shows a lack of bias, but that's a long ways from being a
> > > comprehensive test of a PRNG.
> > >
> >
> > Please check it yourelf.
>
> I have, you idiot.
This proves that your ability to understand something new is NULL.
But I am sure that you are not a Full Idiot.
> > > You PRNG fails some of the FIPS 140-2 tests fairly regularly. It
> > > fails quite a few of the DieHard tests very consistently. Your PRNG
> > > is clearly NOT suitable for cryptographic use.
> >
> > It is only your assumption. Let us proof it.
>
> Quite the contrary -- I HAVE proven it, and you're just too stupid to
> realize it. The code in DieHard that gives values of p=1.0000 gives
> anybody who cares to look at its source code a way of predicting bits
> from your generator with essentially perfect accuracy.
>
> --
> Later,
> Jerry.
>
> The Universe is a figment of its own imagination.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random Number Generator
Date: Mon, 14 Aug 2000 13:43:15 GMT
In article <8n6omm$f2d$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <8n0blf$4al$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
> >Do you think that there is no mapping of finite sets of natural
> >numbers into set of infinite sets of natural numbers?
> >Please evaluate this algorithm and you will believe.
>
> Not with a finite state/memory machine. Your system has only a finite
> set of internal states. Once they are used up, it repeats. It may take a
> while but it will do so.
>
You are right.. But this repetition is not predictable from key/seed.
There is no way to find out key having generated sequence.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 14 Aug 2000 09:52:06 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Crypto Related Professional Attitude
Mok-Kong Shen wrote:
> "Trevor L. Jackson, III" wrote:
> >
> [snip]
> > properties from humans. Since this newsgroup is a (virtual) place of academic
> > congress the behaviors evidenced here are typical of congresses in general.
>
> It is my impression from the few scientific congresses that
> I have attended that the people there are much more polite
> and considerate of other persons than what sometime happens
> in this group. I strongly believe that's one (among other)
> factor that repulse the top researchers from our group.
When one meets people once a year one is dealing with strangers and formal rules
dominate behavior. When one works with a group on a daily basis there is less
inclination to follow rules of formality and simultaneously much more opportunity
for irritation and annoyance. The "sweeping sagas" that occur in research and
engineering groups are far more intense than anything allowed upon US television.
The high intelligence and motivation levels of the participants contribute to the
intensity and perversity of the machinations. Being intelligent is only loosely
correlated with being rational.
Newsgroups are intermediates that tend toward the familiar. C.f., a quote
attributed to Dennis Ritchie: "Usenet is a strange place".
As for the rudeness and lack of consideration, I agree that these are strong
disincentives. That's what thick skins and killfiles are for.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: New Serpent Sboxes
Date: Mon, 14 Aug 2000 14:54:15 +0100
Have you worked out optimal (in respect of "terms") boolean
representations of the S-Boxes? Dr Gladman and myself have spent a
considerable amount of computing power (using a custom program
written by Dr Gladman, available on his site) to find what we
consider to be near optimal terms for the existing boxes.
If not then the boxes will, no doubt, be of theoretical interest but
probably won't be particularly quick>
Regards,
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> For something todo I made some serpent-like sboxes. They are no
> better just different. Ideal for making families of serpent...
>
> For the spec-techs they are 4x4 sboxes where the inverse and
> natural share being fully SAC compliant, BIC compliant (order 3)
> a LP/DP max of 4. I used my newer sboxgen so the SAC test is in
> fact more accurate.
>
> The sboxes are at
>
> http://www.geocties.com/tomstdenis/
>
> Tom
>
>
> -----------------------------------------------------------
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
------------------------------
Date: Mon, 14 Aug 2000 09:55:33 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Crypto Related Professional Attitude
Safuat Hamdy wrote:
> tomstd <[EMAIL PROTECTED]> writes:
>
> > Also why don't those dudes post here to discuss their findings?
>
> Because these findings requires *deep* mathematical knowledge that
> the average sci.crypt reader with probability almost 1 doesn't have.
> Thus is is completely pointless for them to post their work.
Present company excluded of course (DW, BS, & BS), "Those who can, do; those
who can't, teach." If one is "here" talking about crypto, one isn't doing
crypto.
------------------------------
From: haifeng <[EMAIL PROTECTED]>
Subject: entrust software
Date: Mon, 14 Aug 2000 16:58:24 +0300
Hello,
Who used entrust/pki to creat CAs? How can I do it?
I need help.
thanks.
Haifeng:)
------------------------------
Date: Mon, 14 Aug 2000 10:00:40 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Tim Tyler wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
>
> [snip far too much]
>
> : If I understand this correctly it amounts to a claim that a rational attacker
> : will not test for short cycles because the effort expended, when discounted by
> : the odds of success, does not get him any closer to cracking the system than
> : an equivalent amount of effort invested in a QR search. [...]
>
> *If* so, the argument does not appear very convincing. What if the
> attacker has a dedicated, parallel, short-cycle testing machine - built
> for some other purpose - but only a general purpose serial computer
> for use in factoring?
>
> It appears that such an asymmetry could skew his best strategy
> significantly in favour of looking for short cycles rather than
> factoring - in which case eliminating short cycles might
> genuinely help.
>
> This is what I believe Ritter calls an "additional" weakness.
>
> : If so, it is similar to the reasons why one need not check for long stretches
> : of zeros in an OTP key. [...]
>
> I don't like this analogy. I think it has great potential to mislead :-/
I was trying very hard to avoid calling it a statistical conclusion.
>
>
> : Are all opponents sane?
>
> Perhaps not - but its probably not sane to concern yourself overly much
> with any insane ones ;-)
So we should ignore the irrational ones who will cover all bases and thus crack
messages by finding short cycles we've overlooked. I'd rather not over look them.
;-)
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Crypto Related Professional Attitude
Date: 14 Aug 2000 13:57:42 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> Present company excluded of course (DW, BS, & BS), "Those who can, do; those
> who can't, teach." If one is "here" talking about crypto, one isn't doing
> crypto.
Mostly but not always -- sometimes a thread here will have substantive
technical content in the pursuit of a new idea. This is why I still
read the group (that, and an addiction to usenet) at least.
-David
------------------------------
Subject: Re: New Serpent Sboxes
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2000 07:02:17 -0700
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
>Have you worked out optimal (in respect of "terms") boolean
>representations of the S-Boxes? Dr Gladman and myself have
spent a
>considerable amount of computing power (using a custom program
>written by Dr Gladman, available on his site) to find what we
>consider to be near optimal terms for the existing boxes.
>
>If not then the boxes will, no doubt, be of theoretical
interest but
>probably won't be particularly quick>
Well I don't doubt that these sboxes could be turned into
something like the compiled ones since the original sboxes were
not designed with that strictly in mind where they?
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Mon, 14 Aug 2000 20:06:38 -0600
Reply-To: [EMAIL PROTECTED]
>
>
> If you look at each individual event, it seems random. But if you look
> at a large group of events, they follow a certain pattern. That's not
> random.
>
> >So are distribution of quadratic residues of a large prime. [from Bob
> Silverman]
> But you can't prove it...
Actually it is the large group of events that does show ranbom behavior. An
individual event is just a number. For radioactive decay, the events obey a
poisson process.
Second, one can prove the distribution of quadratic residues of large
primes behaves randomly.
See: Mauduit, Christian; Sбrkцzy, Andrбs "On finite pseudorandom binary
sequences. I.
Measure of pseudorandomness, the Legendre symbol." Acta Arith. 82 (1997),
no. 4, 365--377.
------------------------------
Subject: Re: Random Number Generator
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2000 07:04:43 -0700
[EMAIL PROTECTED] wrote:
>> > Please check it yourelf.
>>
>> I have, you idiot.
>
>This proves that your ability to understand something new is
NULL.
>But I am sure that you are not a Full Idiot.
Perhaps this is why people think this group is dreadful.
Why not mind your language when you post here?
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Date: Mon, 14 Aug 2000 10:09:23 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Tim Tyler wrote:
> Mark Wooding <[EMAIL PROTECTED]> wrote:
>
> :> > >- The probability to find in random sequence 0/1
> :> > > value bits is exactly 50%
> :> >
> :> > Gosh really?
> :>
> :> Yes!Gosh.
>
> : Whoops. That's a shame. This is a distinguisher!
>
> Not in itself it isn't. The probability of finding a 0 (or a 1) in a
> genuinely random sequence should also be eactly 50%.
>
> However, apparently there are other problems in this area...
But the probability of finding exactly 50% of each is inversely related to the
message length. So the odds go down exponentially with the number of such
messages.
------------------------------
Subject: Re: Random Number Generator
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2000 07:05:56 -0700
[EMAIL PROTECTED] wrote:
>In article <8n6omm$f2d$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Bill Unruh) wrote:
>> In <8n0blf$4al$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>>
>> >Do you think that there is no mapping of finite sets of
natural
>> >numbers into set of infinite sets of natural numbers?
>> >Please evaluate this algorithm and you will believe.
>>
>> Not with a finite state/memory machine. Your system has only
a finite
>> set of internal states. Once they are used up, it repeats. It
may take a
>> while but it will do so.
>>
>You are right.. But this repetition is not predictable from
key/seed.
>There is no way to find out key having generated sequence.
Prove it. What is the period length?
Plus if I know all of the sequence I don't really care what the
seed is.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random Number Generator
Date: Mon, 14 Aug 2000 14:00:54 GMT
In article <8mtu40$9ck$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Alex Random Number Generator
>
> The objective of this algorithm is to map finite
> key/seed to an infinite sequence of random bytes.
> The implementation has following characteristics:
>
> - 16 byte Key/Seed
> - 57% Avalanche Effect
> - 760Kbyte/sec performance
> - 64 Kbyte generated random string shows Null ZIP
> compression
> - The probability to find in random sequence 0/1
> value bits is exactly 50%
>
> Randomness factors
> - lose overflow bit by addition
> - lose overflow byte by multiplication
>
> Algorithm description, source code and EXE
> can be found and download at
>
> www.alex-encryption.de
>
> Regards.
> Alex.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Algorithm of the procedure Arithm.
Ok. We have 32 byte state labelled EffKey, which is considered for the main
loop as 16 words.
1. Get the next word in Effkey 2. Adr1=word[0] mod 32 // address of the first
operand in Effkey 3. Adr2=word[1] mod 32 // address of the second operand in
Effkey 4. Sum= EffKey[Adr1]+EffKey[Adr2] // sum of two bytes with lose of
overflow bit 5. Mul= EffKey[Adr1]*EffKey[Adr2] // multiplication of two bytes
with lose of overflow byte 6. Effkey[Addr1]=Sum 7. Effkey[Addr2]=Mul 8. GOTO
1
As you can see there is no way to get know which bytes of Effkey are updated
and in which way. Some bytes may be updated more then one time. Procedure
Reflection truncates the state. 50% of information resulted in procedure
Arithm is lost. So, lose of information is my way to randomness.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Random Number Generator
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2000 07:17:12 -0700
[EMAIL PROTECTED] wrote:
>As you can see there is no way to get know which bytes of
Effkey are updated
>and in which way. Some bytes may be updated more then one time.
Procedure
>Reflection truncates the state. 50% of information resulted in
procedure
>Arithm is lost. So, lose of information is my way to randomness.
Um losing entropy is not a good idea. You lose enough entropy
by creating outputs, but simply dumping half the bits is not a
good idea..
Are you sure you have thought this through?
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: New Serpent Sboxes
Date: Mon, 14 Aug 2000 15:21:21 +0100
I believe any Serpent SBoxes can be made into a boolean expression,
it would be interesting to see how "optimal" (or otherwise!) they
really are....
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Sam Simpson" <[EMAIL PROTECTED]> wrote:
> >Have you worked out optimal (in respect of "terms") boolean
> >representations of the S-Boxes? Dr Gladman and myself have
> spent a
> >considerable amount of computing power (using a custom program
> >written by Dr Gladman, available on his site) to find what we
> >consider to be near optimal terms for the existing boxes.
> >
> >If not then the boxes will, no doubt, be of theoretical
> interest but
> >probably won't be particularly quick>
>
> Well I don't doubt that these sboxes could be turned into
> something like the compiled ones since the original sboxes were
> not designed with that strictly in mind where they?
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Playfair-Analyze ?
Date: 14 Aug 2000 14:25:05 GMT
[EMAIL PROTECTED] (Ronny Burow) writes, in part:
>Now i need some help with Playfair. Where can i get
>a simple description how to analyze a playfair-chiffre ?
You can find the Lanaki lessons on my web site on the
"Crypto lessons" page. You'll also find a Playfair
cracking tool on the "Historical" page.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Random Number Generator
Date: 14 Aug 2000 14:25:41 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> Mark Wooding <[EMAIL PROTECTED]> wrote:
>
> :> > >- The probability to find in random sequence 0/1
> :> > > value bits is exactly 50%
> :> >
> :> > Gosh really?
> :>
> :> Yes!Gosh.
>
> : Whoops. That's a shame. This is a distinguisher!
>
> Not in itself it isn't. The probability of finding a 0 (or a 1) in a
> genuinely random sequence should also be eactly 50%.
The problem is that within each output block, we get *exactly* the same
number of zeroes and ones. That's wrong. In a 2 k-bit block, the
probability of actually having the same number of zero and one bits is
\binom{2 k}{k} 2^{-2 k}. This is actually quite small, and an RNG which
has this unfortunate property is very easily distinguishable.
Just because parity is *expected* doesn't make it *likely*. ;-)
-- [mdw]
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 14 Aug 2000 20:27:40 -0600
Reply-To: [EMAIL PROTECTED]
"Trevor L. Jackson, III" wrote:
> If so, it is similar to the reasons why one need not check for long stretches
> of zeros in an OTP key. The odds of a significant fraction of the pad being
> zero are so long that a sane attacker will not even inspect the ciphertext.
> Of course an attacker who does notice a long stretch of intelligible cipher
> text could argue that the odds against the text appearing accidentally are so
> long that a null key pad is the simplest explanation.
>
> Are all opponents sane?
If a long stretch of zeros (length to be determined later) occured in a OTP, I
would assume the generator was broken. Rare events rarely happen. At some point
one decides that the probablity of a cooked generator is greater than that of
getting a string of zeros. The number is somewhere between 1 zero and 100 zeros.
------------------------------
Subject: Re: New Serpent Sboxes
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2000 07:26:57 -0700
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
>I believe any Serpent SBoxes can be made into a boolean
expression,
>it would be interesting to see how "optimal" (or otherwise!)
they
>really are....
Well I can pick up his source code and see what it does if you
want to see...
Decompiling boolean functions is not really my area of expertese
so I don't want to just copy his source without permission first.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Proposal of drafting rules of conduct of posting
Date: 14 Aug 2000 14:34:06 GMT
Mok-Kong Shen [EMAIL PROTECTED] writes, in part:
>I have a suggestion. Wouldn't it be nice that we have
>some thing that I temporarily term to be general rules of
>conduct of posting to the group? (One rule could be e.g.
>'Never use bad words', with a bit explanations.) If there
>are a sufficient number of people who say 'yes' to the
>proposal, we could arrange for a drafting committee for that
>and have the results discussed, amended and finally voted
>for in the large in the group. The rules could then be
>posted, say, every week so that to those posters that don't
>observe the rules the answer could be simply a pointer to
>certain items in that article.
Sounds like a damn silly idea to me.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random Number Generator
Date: Mon, 14 Aug 2000 14:28:56 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8n0aae$3fv$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > Let me ask you how can man implement permutation of bits not using
> > Assembler?
>
> By learning to use a high-level language. Just for example, you
> code:
>
> lea esi, EffKey
> xor ecx, ecx
> xor edx, edx
> @m0:
> xor eax, eax
> xor ebx, ebx
> mov ax, [esi+ecx]
> and al, 1fh
> and ah, 1fh
>
> reduces to the following in C:
>
> short temp;
>
> for (I=0; I<32;I+=2) {
> temp = EffKey[0] + EffKey[1]<<8;
> temp &= 0x1f1fh
>
> Also note that your use of assembly language is _quite_ awful. Just
> for example, it's trivial to combine:
>
> and al, 1fh
> and ah, 1fh
>
> into:
>
> and ax, 1f1fh
>
> This is SO trivial that anybody who doesn't know it should NOT be
> releasing anything they've written in assembly language for public
> consumption. In fact, it's roughly equivalent to wearing a big sign
> on your back saying you're a complete idiot.
>
The first sign to be an idiot is to call some idiot.
You are not an idiot I think.
Ты просто жидяра порхатый.
Чтоб у тебя мозги отсохли сегодня же. Козел.
> > There are no weakness and holes in this algorithm.
>
> This is yet another way of announcing to the world that you have an
> IQ lower than room temperature (measured in Celsius).
>
> --
> Later,
> Jerry.
>
> The Universe is a figment of its own imagination.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random Number Generator
Date: Mon, 14 Aug 2000 14:30:42 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >> > Please check it yourelf.
> >>
> >> I have, you idiot.
> >
> >This proves that your ability to understand something new is
> NULL.
> >But I am sure that you are not a Full Idiot.
>
> Perhaps this is why people think this group is dreadful.
So are You.
>
> Why not mind your language when you post here?
>
> Tom
>
> -----------------------------------------------------------
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Baruch Even <[EMAIL PROTECTED]>
Subject: Re: Preserving confidentiality while linking data?
Date: Mon, 14 Aug 2000 12:57:05 +0200
As was already suggested a cryptographic hash will do the job of
creating an ID, the preferred way is SHA1 since MD5 has had a
collision attack for some time now.
You have also raised the problem of reverse lookup, I couldn't figure
out your solution for this, but generally you'll need a trusted authority
to do the linking, an authority that will not exploit the knowledge, and
it probably should return a random id back so that the actual id
will be harder to get by from the returned information.
A third problem that was raised is the problem of not allowing users
to find information from the linked data, I believe this is usually a hard
problem, with no real solution, there is a field for this in computer
security, but I don't remember its name right now.
If you want a real research info on this subjects you should try
to look for articles on this subjects in the computer security
publications.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Looking for methods to reliably link unit record personal information in
> large administrative data sets without the identity of the people being
> accessible to those using the linked data.
>
> The proposed approach is for the custodians of each data set to
> standardise the name, address and birthdate information according to an
> agreed protocol and then apply a standard one way hash to generate a
> unique id string. This id string then replaces the identifying
> information and the resulting de-identified unit record data can be
> linked with other similarly treated datasets for analysis.
>
> The basis of the approach is that by standardising the format of the
> input data and using a standard hash, then each custodian will generate
> the same hash value given the same input data. To avoid simple reverse
> lookups of has values to input identity an additional step is proposed.
>
> A third party would take each dataset with hashed id and link the
> records using the hash values, then strip the hash values and assign a
> random number id before making the linked data available for analysis
> back to both the data custodians and other researchers.
>
> There remains the problem that if the patterns of values in the fields
> of a record in one data set are sufficiently unique, that a data
> custodian will be able to use that pattern to match a lined record back
> to the identifying information in their own data set and so link an
> identity with the data from another custodian's recordset. Apart from
> deliberately scrambling the data values (and so making the linked data
> valueless for analysis) it is not clear how this can be avoided other
> than by controls on the practices of data custodians such as separating
> within data custodians systems the storage of identifying data and the
> balance of data.
>
> The biggest source of failed linkages (ie no linkages even though the
> records are for the same person) or spurious linkages (linkages of
> records where they are actually for different people) will be problems
> with the address information - classic issues such as surnames changing
> with marriage, or different spellings. In this context the level of
> collisions in the hash (ie the same hash being produced from different
> inputs) is less likely to be an issue. Nevertheless it is worth
> minimising all sources of error, so a hash algorithm with minimal
> collisions is preferred. This should be seen in the context of records
> covering several million people. In the interests of economies of data
> handling, it is is also preferable to have a unique hash output that is
> as short as feasible.
>
> Can someone pls offer views as to the most approporiate has algorithms?
>
> Any other comments on the scheme also welcome.
>
>
------------------------------
** 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
******************************
