Cryptography-Digest Digest #197, Volume #13 Tue, 21 Nov 00 11:13:00 EST
Contents:
Re: "unsecure data structures" ? (Paul Crowley)
Re: More about big block ciphers (Tom St Denis)
Re: S/MIME (Tom St Denis)
Re: [Question] Generation of random keys (Alan Rouse)
Re: vote buying... (Jeffrey Williams)
Re: Cryptogram Newsletter is off the wall? (Daniel James)
Re: Cryptogram Newsletter is off the wall? (Daniel James)
Re: Cryptogram Newsletter is off the wall? (Daniel James)
New Algorithm, and what ? (Sylvain Martinez)
Re: A Simple Voting Procedure ("Tony T. Warnock")
Re: "unsecure data structures" ? (Bob Silverman)
Re: Security of Norton YEO (Your Eyes Only) (Mack)
Re: A Simple Voting Procedure ("Trevor L. Jackson, III")
Re: A Simple Voting Procedure ("Trevor L. Jackson, III")
Re: Algorithm with minimum RAM usage? (Mack)
Re: vote buying... ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: "unsecure data structures" ?
Date: Tue, 21 Nov 2000 11:57:10 GMT
Rainer Nausedat wrote:
> Am I right if I assume that one could easily break such a header if is
> encrypted ? dwFileCrc for example could be least any 32bit value, but
> dwFileAttribute is one of say 12 known possible values, and
> cCompressionMethod is one 6 known possible values etc.
Fortunately, no. If you correctly implement strong crypto, you don't
have to worry at all about massaging your data formats to be "crypto
friendly": strong ciphers resist known and even chosen plaintext attack.
Correctly implementing strong crypto is tricky however. CTR mode
Rijndael is likely to become a US national standard soon, and isn't too
hard to implement using one of the free Rijndael implementations; it's
also rather fast. However, if you can use a library like OpenSSL you'll
be better off. Still, there will be many other issues to consider in
building a strong system and you should consider getting a security
consultant in to review what you're doing if you need security.
Schneier's "Secrets and Lies" provides a good perspective.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: More about big block ciphers
Date: Tue, 21 Nov 2000 11:48:33 GMT
In article <8vdg9j$48m$[EMAIL PROTECTED]>,
Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
> In article <8vceh3$a0b$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <d1fS5.294$[EMAIL PROTECTED]>,
> > "Manuel Pancorbo" <[EMAIL PROTECTED]> wrote:
> > > **** Huge-block cipher BUTTERFLY ****
> > >
> > > In a previous thread I discussed with some of you about big-block
> > ciphers
> > > with a feedback stream engine. Now I present my own proposal that
I
> > name
> > > "butterfly". See source code, testvectors, performance test
programs
> > and so
> > > on in:
> >
> > I already posted why your S0[S1[x xor k) <<< 4] is a bad mixing
> > function (when S0/S1 are parallel 8x8 substitutions).
> >
> > If I misunderstood then I am sorry, but if you are not listening
SHAME
> > ON YOU!
> >
>
> Shame on your eyes or on your news server Tom. I did post an answer to
> your objection (11, 17 2000). Again:
>
> <answer> This apply when x is 8-bit and S acts on 8-bits words. But in
> this case x is 32-bit and there is 4 8bit-sboxes; so the intermediate
> rotation is usefull. </answer>
<smarteranswer>Consider any difference that has input/output under 5
bits and is in the lsb position.</smarteranswer>
> Of course the mixing is not complete but the cipher is not only its
> stream engine but the way this is applied on the packet. Please take a
> glance at the source code (bfly.c).
If the mixing is not 'complete' then your diffusion is hardly "ideal".
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: S/MIME
Date: Tue, 21 Nov 2000 11:50:22 GMT
In article <8vci72$d0q$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Would anyone happen to know the key differences between S/MIMEv2 and
> S/MIMEv3. Is it just the addition of more encryption algoritms?
hmm.. With more algorithms it must be better, no question about it.
hehehe.
40-bit RC2 all the way!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Tue, 21 Nov 2000 13:02:55 GMT
The original post on this thread was requesting source code to generate
a random key. I've never seen source code that could flip a coin or
roll dice.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Tue, 21 Nov 2000 07:35:07 -0600
Although I'll point out that voting in person doesn't prevent fraud. According
to my American friends, to get a voter registration card, one needs a valid
picture id (driver's licence, for example) and a social security card. I have a
Texas driver's licence and a social security number. I'm a Canadian living in
Texas.
Even those qualifications are suspect; I know people who presented neither and
were given voter registration.
It would seem to me that foreigners can vote, and that it is possible for anyone
to register to vote multiple times. I do not see how your system is fair,
honest, or trustworthy. I do not see how it can be without some form of national
(or state-wide) identification card.
Paul Rubin wrote:
> Shawn Willden <[EMAIL PROTECTED]> writes:
> > It's interesting to note that the voting schemes we currently use fail this
> > test as well. If I want to buy your vote, I just have you request an
> > absentee ballot which I fill out for you and mail in. Maybe this isn't an
> > important test.
>
> Yes, absentee ballots have been abused more and more in recent
> elections, including in vote buying and vote trading schemes. I
> believe measures should be taken to curb such abuse. In most states
> voting is allowed only if you CAN'T vote at the polls (e.g. you will
> be away from your district on election day). But people routinely
> ignore this rule and vote absentee to avoid the trip to the polls.
>
> Absentee ballots are also a popular vehicle for fraud. Xavier Juarez
> got himself elected mayor of Miami by absentee fraud, and then was
> thrown out of office when the fraud was discovered and the absentee
> vote was invalidated. (He did not become unemployed though. He was
> put in charge of sending out absentee ballots for a certain
> Presidential campaign this year, that I guess decided to hire a man
> with experience). By cutting down the amount of absentee voting,
> the level of practicable fraud can also be reduced.
>
> Apparently under the law, absentee voting is a privilege rather than a
> right--I don't think I agree with that, but I can think of some
> reforms I'd like to see put in place.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Tue, 21 Nov 2000 13:35:21 GMT
Reply-To: [EMAIL PROTECTED]
In article <8vb58b$50d$[EMAIL PROTECTED]>, wrote:
> That depends on how your application is written. If there are security
> features in your application, which says something like:
>
> OK This message is designated to go into the smart card...
> Put this message in a designated and secure are of memory
> ...
So, I just make a copy of your application that doesn't work in this way
- that's just a variation on the Trojan Horse attack I mentioned before.
The trick to making sure that this type of system is secure is to ensure
that you know that trust all the software in your system.
Cheers,
Daniel.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Tue, 21 Nov 2000 13:35:22 GMT
Reply-To: [EMAIL PROTECTED]
In article <8vbej1$cmp$[EMAIL PROTECTED]>, wrote:
> ... Its even feasible that the card could have a little LCD display
> so that you could visibly verify the document, data or content hash.
You would have to verify the whole doument, otherwise the possibility
still exists that a Trojan is feeding a false hash into your secure
environment. It's certainly a possibility, though reviewing a long
document would be somewhat impractical.
Cheers,
Daniel.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Tue, 21 Nov 2000 13:35:22 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Benjamin Goldberg wrote:
> Would a paper and ink analogy be slipping a sheet of carbon paper
> beneath a contract, and having another, different contract beneath?
Yes, that's very good as far as it goes. If a carbon copy were
indistinguishable from a top copy it would be perfect.
Cheers,
Daniel.
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: New Algorithm, and what ?
Date: Tue, 21 Nov 2000 13:40:16 GMT
Hi sci.crypt !
NOTE: sorry for my bad english, but it is not my mother tongue language.
BUGS is a relatively new private key algorithm. It does not claim to be
the best algorithm in the world, because as any "home-made" cryptography
algorithm it can't be. It is just the result of a strong interests I've
got in cryptography.
Nevertheless, it is not that bad...
Before you skip or *clonk* this thread please let me explain why I think
this BUGS algorithm could be interesting and why I am doing it for.
And why there is a new version 4.0.0 !
- I think BUGS is interesting because it is different from the current
cryptography
algorithms available (not that they are bad ;o), it is a DYNAMIC
algorithm.
This means that the algorithm will behave differently in function of
the password/key used to crypt a file. I know other algorithms could
also
be defined as "dynamic" but I think this one is the one of the
most "Dynamic" out there.
- I am interested in cryptography, I am not an expert, I am not even an
"amateur".
I like the "Unix spirit" and I just wanted to create something
opensource/multiplatform.
I like challenges, I know that before you create your own algorithm you
need to at least read many books and try to crack some algorithms first.
I've just read books (nearly forgot to put an 's' at the end ;o).
In order to interests as most people as possible I did not just create
an algorithm on its own. I've created many applications arround on Unix
and Windows and a long documentation. I have even started 2 contests
(£100 to win) just to see how far this BUGS algorithm can go.
If you are still interested here comes the technical bit.
(I would have went straight to the point if I didn't know how careful
you
have to be before posting something on sci.crypt ...
and I'm sure it won't be enough ;o)
-- BUGS v4.0.0 --
http://www.bcrypt.com
Platform: Unix, Windows (tested on solaris,linux,true64,bsd,hpux,cgi)
Dynamic private key algorithm.
I will first describe how the algorithm works in a nutshell and then
give a
full description of the key generation process
A) In a nutshell
-To crypt a file you enter a password that will be converted into a key.
This key is generated from the password by a series of bits swap and
bits operations (AND,NOR,OR, etc) and then a random number is generated
(using ISAAC algorithm or "bad" standard C rand())
The bits swap+operations will change in function of the password
itself.
-The key will then be reused to generate other similar keys, in order to
get a buffer of keys (default = 16 keys).
-2 keys from the key buffer will be mixed together anf the result
KEY_TEMP will be used as a password to generate a new key: KEYX which
will be XORed to one block of the file (the size of this block is the
same as the key's length)
The sequence in which the blocks are XORed is function of the password.
-The key which has just been used, KEYX, will replace one of the 2 keys
used in the buffer in order to "re-populate" the buffer.
-Once all the blocks of the file have been XORed the block shuffle (BS)
can start.
-By default the BS is 4 bytes. The file will be divided into blocks
the size of BS (ie. 4 bytes), then in function of the password 2
blocks will be picked up pseudo-randomly from the file, mixed together
and the result XORed to another pseudo-randomly chosen block of the
file.
This allows the algorithm to crypt the file with its own data.
-You can make all this cryptography process much more complex by
changing few parameters:
In the previous example you were working with all the data of the file
(I mean that you could start to XOR the first block of the file and
then jump to the LAST block)
but you can also specify a BLOCK CRYPT, which if set to 50 bytes for
example,
will only work within the first 50 bytes of the file and then with the
50 following bytes, and so on.
The size of the block shuffle (BS) can be changed as well and can be
set to dynamically change at each round in function of the password !
-Dynamic is one of the KEYWORD of this algorithm.
I hope I am not miss-using this word.
But during the key generation the number of round (cycle where the bits
will be swapped) can change dependanding of the password you've
entered,
the distance between 2 bits to be swapped will also depand on your
password.
During the XOR process, the size of the Key Buffer can also change in
function of your password.
The algorithm has been carefully tested against bugs and should be
pretty stable now.
It is slow. but I believe it is relatively secure, at least secure
enough to protect your data against anybody who hasn't got access to
government's computer ;o)
Many people tried to crack the previous algorithm and sent me reports
about what could be done to make it better, this version is the results
of these comments. One person especially spent a lot of times and energy
analasysing the strength of this algorithm (as I don't really know if he
wants to be named on this forum, I'll call him Simon).
He has also participated into the optimisation of this new algorithm.
The tests done to crack the algorithm were first to find any weaknesses
into the algorithm itself and then a mix between brute force and
"intelligent" reverse ingeneering. I can't really speak about that as
a) I'm not one of the guy who done it and I'm not too familiar with it
anyway
b) There are 2 contests still going on and even if the money prize is
not that
great some people are still doing it for the fun/challenge/principle of
it.
For more information please go to the WEBSITE:
http://www.bcrypt.com
direct Unix Download: http://www.bcrypt.com/crypto/bugs-4.0.0.tgz
direct Doc Download: http://www.bcrypt.com/crypto/doc/fullbugs_40.zip
direct Windows downl: http://www.bcrypt.com/crypto/bcrypt4_1.zip
Online Documentation: http://www.bcrypt.com/crypto/doc/index/html
Here is a more detailed explanation about the KEY GENERATION process.
You enter a password, this password will be converted into a KEY as
follow:
1.1) pwd converted into an integer array
1.2) all the numbers of this array will be added together and the
result(sort of checksum) will be added to each integer of the array
This checksum number will change each time it is added as follow:
NB_BITS = how many bits are used by your INTEGER type
SHIFT = of of the integer of the array
nb_toadd = (nb_toadd >> SHIFT) | (nb_toadd << (NB_BITS - SHIFT))
1.3)The number of ROUND will change in function of your password (the
maximum value is double the default value) and it will affect the
number of cycle done for this part of the key generation.
During one cycle (ROUND) at least half of the bits of the key will be
swapped. Also at least half of the bits will have had a Logical
operation
for example:
bit1, bit2
bit1 = bit1 & bit2
bit2 = bit1 | bit2
The swap and Logical operation are bilateral (the first of the 2 bits
will be once chosen from the "left" and then from the "right", "left",
etc)
To be able to have SWAP between bits distant from a lot of bits and
also from only few bits, 2 modulo swap will be generated and used
alternatively to decide what will be the maximum bits distance
betweem 2 bits.
There are a SMALL_MODULO_SWAP and a BIG_MODULO_SWAP
by default the SMALL_MOD = your keylength / 2
and the BIG_MOD = your keylength
You can decide or not to dynamically change these modulo in function
of your password at each round. The SMALL_MOD value will still be
between(1 and your_keylength/2) and BIG_MOD between (1 and
your_keylength) but these values will change at each round.
1.4) A random number will be added to the KEY.
We first generate a random number using ISAAC and then XOR the result
to the key, then use the random number into a LFSR to generate another
pseudo random number, and so on.
This is not a really important step, as it does not really add any
security to BUGS. (according to "Simon" :)
That's it. There is much more information on my website
(http://www.bcrypt.com)
I guess I'm gonna get flamed (at least because this post is far too
long) but I'm just interested into what people who know cryptography
thinks about this little algorithm. I'm not looking for fame or fight
but just feedback.
Hope you'll enjoy it.
Sylvain.
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 21 Nov 2000 07:39:38 -0700
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Captain of the Guard comes knocking on your door, points a gun at your
> head and politely requests your assistance is solving whether or not
> you voted a particular way. If you voted wrong he'll shoot you, if you
> refuse to cooperate he'll shoot you. I personally would not want it to
> be possible to forcibly coerse someone like that. Also if you cannot
> prove how you voted, someone cannot reliably buy your vote.
>"Also if you cannot prove how you voted, someone cannot reliably buy your
vote. "
One can increase the reliability by "outcome oriented threats" (or
rewards). One makes the threat contingent upon the outcome--if the Captain
of the Guard's candidate doesn't win, he shoots you (or fails to increase
your entitlements.)
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: "unsecure data structures" ?
Date: Tue, 21 Nov 2000 15:38:28 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Rainer Nausedat wrote:
> > Am I right if I assume that one could easily break such a header if
is
> > encrypted ? dwFileCrc for example could be least any 32bit value,
but
> > dwFileAttribute is one of say 12 known possible values, and
> > cCompressionMethod is one 6 known possible values etc.
>
> Fortunately, no. If you correctly implement strong crypto, you don't
> have to worry at all about massaging your data formats to be "crypto
> friendly": strong ciphers resist known and even chosen plaintext
attack.
Correct. But what we have here ISN'T a known plain text attack.
It is a dictionary attack; a different beast altogether.
In this case, all an attacker need do is to encrypt
2^32 * 12 * 6 * (however many different values there are for the other
variables)
different possible messages and then see which one matches the
ciphertext. i.e. the analyst guesses the possible different fields.
This is far less computation than any other known method of
attack.
What I would recomment to the user is to add a large random number
to the data structure.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 21 Nov 2000 15:50:36 GMT
Subject: Re: Security of Norton YEO (Your Eyes Only)
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Does anyone know of any security issues with Norton YEO? I know that
>the
>> encryption methods that they use are good, but I'm wondering if there
>are any
>> known bugs or if they left in a backdoor.
>>
>> Thanks,
>>
>> Brad
>>
>I _THINK_ that this program uses DES56. DES-56 is insecure against
>brute-force. To quantify this statement, it took distributed.net (a
>server dedicated to breaking ciphers by brute-force) managed to break
>des-56 in well under 24-hours.
>
>This said, it is probably well outside the reach of most people. I'd
>say about 98% of individuals and 85% of companies.
>
>As for back-doors, the program isn't open-source so there is no way
>this can be determined. Unless, of course, you reverse engineer the
>program but this always against the terms and conditions the program
>has you agree to before installation.
>
>PGP is open source, and can be downloaded from pgpi.org..... The
>algorithms it uses are more secure, and since it is open-source you know
>that the copy you compile is free of back doors.
>
>hope i was of some use,
>
>Simon.
>--
>Hi, i'm the signuture virus,
>help me spread by copying me into Signiture File
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
An early version of YEO was also case insensitive and did use
DES-56 but only allowed alphanumeric characters. This gives
an effective strength of 2**41 or there abouts. Anyway this
made it exportable. Don't know if this is still the case.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Tue, 21 Nov 2000 10:54:37 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
David Schwartz wrote:
> Paul Rubin wrote:
> >
> > David Schwartz <[EMAIL PROTECTED]> writes:
> > > > Quite the opposite. If the voter can help, the oppressive regime can
> > > > and will demand the help, under threat of torture or whatever. So the
> > > > voter must be unable to help.
> > >
> > > What a non-sequiter! Who said the voter can't trivially make himself
> > > unable to help if he wants to? Can you please answer the question I'm
> > > asking.
> >
> > I'm missing something. If the voter is able to help, the oppressor
> > says "provide help OR ELSE". If the voter makes himself unable to
> > help, that counts as refusing to provide help. I don't want a system
> > where the voter can decide whether or not to provide help. I want
> > a system where the voter CANNOT provide help.
>
> You can have a system where the voter both can and cannot provide help.
> Consider, for example, a system where the voter gets an electronic
> receipt which he can either keep or throw out. Or you can have a system
> where there are 'dummy' receipts that look genuine in all ways to
> officials and wherein a voter can produce a dummy or the real receipt
> and an official couldn't tell which is which. So just because the voter
> can help if he chooses to, it does not follow that the voter can be
> compelled to help.
>
> Now, the question I'm asking is, is there any objection to a system
> where the voter and an official can, with mutual consent, determine how
> the voter voted?
The answer is "yes". That is spelled Y. E. S. If you find this confusing please
indicate which letter you do not comprehend.
------------------------------
Date: Tue, 21 Nov 2000 10:56:17 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Paul Rubin wrote:
> David Schwartz <[EMAIL PROTECTED]> writes:
> > You can have a system where the voter both can and cannot provide help.
> > Consider, for example, a system where the voter gets an electronic
> > receipt which he can either keep or throw out. Or you can have a system
> > where there are 'dummy' receipts that look genuine in all ways to
> > officials and wherein a voter can produce a dummy or the real receipt
> > and an official couldn't tell which is which. So just because the voter
> > can help if he chooses to, it does not follow that the voter can be
> > compelled to help.
>
> Huh? What are receipts like that good for?
>
> Dudley Do-right (good guy) and Snidely Whiplash (bad guy) have an
> election. Dudley wins by a 3-vote margin. 1000 of Snidely's
> supporters get together with their dummy receipts and go on TV saying
> the election was rigged. They produce their dummy receipts that show
> they voted for Snidely and yet the official rolls (when decrypted by
> the dummy receipts, which they claim are real receipts) show they
> voted Snidely.
>
> Receipts that don't prove anything aren't worth anything.
... to the honest voter. However, they are extremely valuable to the dishonest
voter/official/candidate.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 21 Nov 2000 16:01:45 GMT
Subject: Re: Algorithm with minimum RAM usage?
>I sometimes program microcontrollers where my old standby ARCFOUR
>can't be used because it takes too much RAM. What strong encryption
>algorithm uses the minimum amount of RAM?
>
>I have virtually unlimited amounts of ROM, and the application
>is such that I have a virtually unlimited amount of CPU time to
>burn, so efficiency and size are non-issues.
>
>
>
>
You might try Q
http://members.aol.com/_ht_a/macckone/prod01.htm
It was presented at NESSIE last week.
It has been 'broken' but the attack requires at least
2**115 plaintext/ciphertext pairs. This algorithm allows
ciphering to take place with only the key and the plaintext
and 8 additional bytes in memory. The 8 bytes can also
be eliminated if speed is not an issue. The broken version uses
8 or 9 rounds. 10 rounds is still secure.
Note that this is a new cipher so there may be additional
weaknesses. The same conference also had a few
more ciphers. Noekeon is very simple and elegant and
is produced by the Rijndael team. It is faster and simpler.
see
http://cryptonessie.org/
for more details
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Tue, 21 Nov 2000 11:10:14 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Jeffrey Williams wrote:
> Although I'll point out that voting in person doesn't prevent fraud. According
> to my American friends, to get a voter registration card, one needs a valid
> picture id (driver's licence, for example) and a social security card. I have a
> Texas driver's licence and a social security number. I'm a Canadian living in
> Texas.
>
> Even those qualifications are suspect; I know people who presented neither and
> were given voter registration.
>
> It would seem to me that foreigners can vote, and that it is possible for anyone
> to register to vote multiple times. I do not see how your system is fair,
> honest, or trustworthy. I do not see how it can be without some form of national
> (or state-wide) identification card.
So people will be able to register to vote without showing their national ID cards?
How does this help?
------------------------------
** 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
******************************
