Cryptography-Digest Digest #996, Volume #10 Fri, 28 Jan 00 19:13:01 EST
Contents:
Help needed on peculiar use of cryptography (Sgwbutcher)
Read my messages in alt.politics.org.cia - you will be satisfied ! (Markku J.
Saarelainen)
Re: Mac encryption algorithm? ("Joseph Ashwood")
Re: Help needed on peculiar use of cryptography (John Savard)
Re: Help needed on peculiar use of cryptography (David A Molnar)
Re: Mac encryption algorithm? (Paul Koning)
Re: DES Hardare - chips/cores (Paul Koning)
Re: Pencil & paper cipher question (r.e.s.)
Re: designing secure backdoors into the system ("Peter K. Boucher")
Re: designing secure backdoors into the system (Paul Koning)
Re: designing secure backdoors into the system (Samuel Paik)
Re: Intel 810 chipset Random Number Generator (Terry Ritter)
Crypto/Security/Cryptanalysis Papers ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Sgwbutcher)
Subject: Help needed on peculiar use of cryptography
Date: 28 Jan 2000 21:27:34 GMT
Dear forum,
I am an economist and in the course of my work, I often have access to
sensitive information. For example, in a discrimination case, I may have access
to personnel records covering several years for all the employees of a company.
Because I often have to match records across different payperiods, months and
years, a unique identifier is required for each record, often the social
security number. Because of various laws and company policies about the use of
social security numbers or any other identifier, I always sign a
confidentiality agreement with regard to the disclosure of this information.
However, sometimes companies are unwilling to part with information even in the
case of confidentiality agreements.
My question is "is there a way that encryption or a specific use or kind of
encryption can be used so that, say, a social security number can be encrypted
so that the informational value of the cyphertext can be retained but the
plaintext cannot be recovered? and is the code for this method accessible as
the actual implementation may be, depending on the case, in Excel, SAS, C/C++,
Perl or Java?"
I think the most important points are (1) this is permanent encryption--is no
"legitimate" reason why the cyphertext would ever be decrypted and (2) the
domain of the plaintext is very small, 0-9 and short length cyphertext and (3)
the information value of the cyphertext should be the same as the plaintext,
that is, if plaintext A identifies a particular record over 5 years, then
cyphertext A should reference the same records and no others.
One obvious solution is to come up with a new identifier scheme, the problem is
that many IT/DP departments are unwilling to invest the effort and the
databases can be quite large and there may be multiple identifiers.
Additionally, in the case of employee numbers, a simple start at 1001 and go on
approach is how they got their employee numbers to begin with so although you
don't have necessarily the employee number you're looking for, you do have
someone's employee number. This is why I'm looking for something a little more
algorithmic.
Any possible help/suggestions you might be able to provide would be
appreciated.
Thanks,
Steve
==========================================================================
======
Stephyn G. W. Butcher
Consultant in Labor Economics and Statistics
1760 Euclid St. NW Suite 306
Washington, DC 20009
(202) 745-0114 fax: (202) 745-0446
[EMAIL PROTECTED]
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Subject: Read my messages in alt.politics.org.cia - you will be satisfied !
Date: Fri, 28 Jan 2000 21:19:28 GMT
Read my messages in alt.politics.org.cia - you will be satisfied.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm?
Date: Fri, 28 Jan 2000 13:35:49 -0000
> And why is this byte order "wrong" ? Little Endian and
Big
> Endian are merely two different byte orders, both of which
have
> their advantages and disadvantages.
There are actually algorythms that require a specific
Endianness to be secure. I can't think of which one offhand,
but IIRC an AES candidate was one of these.
Joe
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help needed on peculiar use of cryptography
Date: Fri, 28 Jan 2000 14:58:43 GMT
[EMAIL PROTECTED] (Sgwbutcher) wrote, in part:
>a social security number can be encrypted
>so that the informational value of the cyphertext can be retained but the
>plaintext cannot be recovered?
It is not clear what this wording means. However, a one-way hash
function can allow a social security number to be encrypted so that,
althought the social security number itself cannot be recovered, its
hash is still usable as an identifier by which records can be matched.
Is this the sort of thing you mean?
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Help needed on peculiar use of cryptography
Date: 28 Jan 2000 21:37:29 GMT
Sgwbutcher <[EMAIL PROTECTED]> wrote:
> I think the most important points are (1) this is permanent encryption--is no
> "legitimate" reason why the cyphertext would ever be decrypted and (2) the
> domain of the plaintext is very small, 0-9 and short length cyphertext and (3)
> the information value of the cyphertext should be the same as the plaintext,
> that is, if plaintext A identifies a particular record over 5 years, then
> cyphertext A should reference the same records and no others.
You might have the company pick a very long, fixed string and keep that
string secret. Then concatenate this string, or "salt", with each of
the ID numbers.
Feed the result to a one-way hash function. One such candidate is
SHA-1. It will be very difficult (almost impossible) to retrieve
the original ID number from the result. At the same time, one
ID number will map to one ciphertext, and the same one everywhere.
So you will be able to do your work.
The reason the company picks a "salt" is to prevent you or anyone
else from guessing identifiers and feeding them to the hash function.
That is, it prevents someone from computing hash(1001) and looking
for the result in your documents. The company must keep this salt secret
for as long as the data is valuable..but I think that's the only secret
they have to keep.
Code implementing SHA-1 is available in a variety of languages. A web
search will turn up some of them, I think.
How does this sound?
Thanks,
-David
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm?
Date: Fri, 28 Jan 2000 17:02:13 -0500
Paul Schlyter wrote:
>
> In article <[EMAIL PROTECTED]>,
> Paul Koning <[EMAIL PROTECTED]> wrote:
>
> > About the only hassle you may run into is that some want to do
> > arithmetic on multi-byte values in the wrong (Intel style) byte
> > order.
>
> And why is this byte order "wrong" ? Little Endian and Big
> Endian are merely two different byte orders, both of which have
> their advantages and disadvantages.
>
> Ever read Gulliver's travels?
No, but I read "on holy wars, and a plea for peace" which is
the paper that brought the terms "big endian" and "little
endian" into high tech terminology.
In any case, when I said "wrong" I meant from the perspective
of implementing communications systems. Networking protocols
almost without exception use big endian. (Only exception I know
of is DECnet.)
Then again, probably because the designers had PCs at hand,
a few crypto algorithms are little endian. MD5 comes to mind.
SHA-1 is big endian, though. That's confused some implementers...
DES is not endian at all in its design, though of course
implementations often are.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES Hardare - chips/cores
Date: Fri, 28 Jan 2000 17:04:04 -0500
[EMAIL PROTECTED] wrote:
>
> I am trying to find standard chip sets/FPGA cores to perform DES-56
> encryption on a OC-3 (155Mbps) ATM cell stream. I also need to do the
> encryption in counter mode. Can you please recommend commercial chip
> sets / FPGA cores that I can use to do DES-56 in counter mode. I am a
> novice to the encryption world.
I don't know any off the shelf chips that do counter mode, and
since they generally do packet encryption it's not easy to adapt
them to do it with external hardware. Probably an FPGA core with
your own stuff around them is best, see the other replies.
For DES in CBC mode, there are plenty of choices: Hi/fn, Analog
Devices/IRE,
Chrysalis, BlueSteel, to name just a few.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: r.e.s. <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Fri, 28 Jan 2000 22:09:11 GMT
Uri Blumenthal wrote:
> John Savard wrote:
[...]
> > The use of a straddling checkerboard, so that you can add digits
> > instead of using a 26 x 26 Vigenere table is then advisable.
> >
> > You might get some ideas from my page. I'd recommend something
> > involving fractionation. <http://www.ecn.ab.ca/~jsavard/crypto.htm>
>
> Yes, a very good advice. My vote goes for VIC. It's bloody hard
> to memorize the generation sequence, but once it's done, it's
> quite secure.
It was quite secure before the algorithm became well-known, but
if an opponent knows that VIC is the cipher you're using, then the
effective keyspace entropy is no more than ~36 bits. (I'm referring
to the VIC cipher as described on John Savard's website, mentioned
above.)
The VIC cipher uses a "passphrase" of 6 digits and 20 letters, but
processes it down to a critical string of 10 digits (i.e. 33 bits),
and this string completely specifies both a straddling checkerboard
and a double transposition, assuming the algorithm is known. Even
if we add another 3.3 bits for the one digit used to hide the message
key, that's still only ~36 bits.
So it seems to me that to be reasonably secure, the VIC cipher
needs to be modified, say to lengthen its "critical digit string"
to ~20 digits, for ~66 bits of entropy. (And correspondingly longer
passphrases should then be incorporated.)
But as for the main crypto components (the straddling checkerboard
& double transposition) -- they represent well over 100 bits of
entropy to a brute-force attack. In fact, the checkerboard (even
assuming it's built around a known permutation of the alphabet) has
at least 10! keys -- 22 bits -- and the double transposition with
variable column widths has a number of keys equal to
sum(m!n!, m=lo..hi, n=lo..hi, m=/=n). With lo=11 and hi=20,
corresponding to VIC having a "personal id#" of 10, the latter
amount is ~119 bits. (A pid# of 8 would give ~102 bits.) If we
include the single digit used to hide the message key (3.3 bits),
this means the total entropy *potential* of the cipher is at least
~134 bits against a brute-force attack. But to take advantage of
that potential, these components would need to be "packaged" more
securely than in the published version.
(I wish I had a better idea of the difficulty of "breaking" the
sort of double transposition involved here -- it's esp. difficult
because although the first stage transposition uses a simple keyed
row-wise fill, the second one uses a keyed "serrated fill".
Considering also that the column widths are random, and that the
symbols are fractionated digits with a quite uniform frequency
distribution, it's hard to believe that this could be anywhere
close to breakable in practice, if properly "packaged" as
described above.)
--
r.e.s.
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 28 Jan 2000 15:33:10 -0700
From: "Peter K. Boucher" <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
How about creating a "repair" account with the appropriate admin
privileges, and partitioning the authentication secrets for it into
"shares" that are held by X number of officers of the company, requiring
Y (some number <= X) shares to get access to the secrets and log into
the repair account?
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?
>
> Regards,
> Yusuf
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
Date: Fri, 28 Jan 2000 17:14:48 -0500
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).
You might use a secret sharing mechanism (see Shamir "How to share
a secret"). That's cleaner than having a back door.
If you do put in a back door, be sure to say so in the documentation.
Nothing will destroy your product faster than having it be discovered
after the fact that you put in a back door -- however protected,
however well intentioned -- without telling people.
paul
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: designing secure backdoors into the system
Date: Fri, 28 Jan 2000 23:08:17 GMT
How about something simpler: lock a piece of paper with the administrator
password in a bank lock box.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
Solyent Green is kitniyos!
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Fri, 28 Jan 2000 23:22:42 GMT
Sorry if this is a duplicate...
On Thu, 27 Jan 2000 08:53:01 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
(Scott Nelson) wrote:
>[...]
>This is sort of what I had in mind:
> ______
>20 Mhrtz | |
>----------D| |Q------
> |74F401|
>1 Mhrtz | |
>---------CP| |
> |______|
>
>The select lines S0, S2, MR, and ground are tied low
>CWE, /P, and VCC are tied high
>
>I'm Ignoring the conversion from crystal to logic levels,
>since it's conceivable that you already have the two circuits
>around. And I'm also assuming the two signals are independent
>(i.e. the 1 Mhrtz signal isn't a divided version of the 20,)
>and that the crystals are physically isolated enough that they
>do not "tune" each other (yet another reason not to use them.)
>
>Since D is gated on the rising edge of CP,
>the "window" is approximately equal to one gate delay.
>5 nano-seconds is pushing it, but within tolerance
>for modern ICs.
I don't think this is what I would call a "window." Jitter may change
the position of an edge by only a tiny amount, but there is *some*
position of the sample before which it will have one value, and after
which it will have another. The effect of the jitter is thus to
change the value of some sample that otherwise would not quite make
that invisible edge.
But no matter how fast the logic may be, we will frequently violate
setup and hold timings in this deliberately asynchronous circuit. In
practice, this will have the effect of skewing what otherwise would be
an ideal 0 / 1 balance, and probably will have much more of an effect
than the jitter. But this will not *be* random, even though it may
*look* random.
>After only 1 million pulses of the CP line, Q will produce
>one reasonably unbiased and unpredictable bit.
>(Assuming that the figure of 1 pico-second of jitter is accurate,
>and I didn't make any mistakes.)
OK, first of all, we note that Q is going to be flopping up and down
quite a bit. This happens even if we assume ideal jitter-free clocks.
That is the natural result of sampling one clock with another. Our
task, then, is to distinguish or detect the rare unexpected
jitter-based sample value from a massive pile of expected ideal sample
values that nevertheless may appear irregular.
The obvious approach is to take the parity of all the samples, which
we can do with another FF. But since this signal also will be
changing frequently, the external sample time becomes critical to
detecting a noise effect, and variations in external sampling times
are likely to have much more of an effect than the detected noise.
This is especially the case when we realize that noise can affect both
edges, and even heavy noise may generally balance out.
I think it would be very difficult to certify such a circuit. There
are so many random-like things going on which are not random that the
presence of fundamentally random effects is obscured. That is not
what we want.
Why are we going through all this? If we want to detect fundamentally
random noise, why don't we just produce some baseband noise and square
it up?
>[more snip]
>>And all this is vastly more than we need if we just want to detect
>>noise.
>>
>Absolutely.
>But there are things like Niko's random number generator,
>so it would be nice to have a quantifiable measure of
>how much (or more precisely, how little) entropy there
>really is in such a thing.
The whole point of understanding how things work is to be able to
predict how they will work in different applications or situations.
"Niko's RNG" is simply not what it is claimed to be. We have a
design, the effect is random-like data, but it is claimed that this
comes from fundamentally random noise. That claim is false. In fact,
the observed effect comes from perhaps unexpected but still quite
deterministic computer operations which are then randomized and
obscured in other deterministic ways. Now, if that is sufficient,
then fine. But if we foolishly believed the original propaganda about
the source being fundamentally random, we might well "turn our back"
on the RNG problem as being absolutely solved and theoretically
secure, and we would be wrong.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Crypto/Security/Cryptanalysis Papers
Date: Fri, 28 Jan 2000 15:20:38 -0000
I recently had a hard drive go bad, and I'm rebuilding what
was on it. So I'm looking for any and all sources of
cryptanalysis papers available. If anyone has any sources
(I'm downloading everything from Counterpane and AES as I
write this) please e-mail me the information (or respond on
group, I'll find it).
Joe
------------------------------
** 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
******************************
