Cryptography-Digest Digest #996, Volume #12 Tue, 24 Oct 00 21:13:01 EDT
Contents:
Re: On block encryption processing with intermediate permutations (James Felling)
Re: Rijndael implementations (Tim Tyler)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: GCHQ Challenge (CiPHER)
Re: My comments on AES (Bryan Olson)
Re: Discrete Log Question (Bob Silverman)
Re: SHA-384 and SHA-512 (John Savard)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: I am after a simple one-way encryption algorithm (H.Bruijn)
Re: I am after a simple one-way encryption algorithm (H.Bruijn)
Re: idea for spam free email ("G. Orme")
Re: Finding Sample implementation for DES and IDEA (Steven Wu)
IEEE P1363 Meeting Announcement ("Jerome A. Solinas")
Re: How to post absolutely anything on the Internet anonymously (Eric Smith)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Tue, 24 Oct 2000 14:57:05 -0500
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
> >
> > > Suppose one encrypts many double blocks (u, v, u, v) in
> > > a very long message
> > [...]
> > > I am afraid
> > > that, by going through 8 cycles it would be extremely
> > > hard to identify a path like (u,v,u,v)-->(x,y,x,y)-->
> > > (e,f,e,f) .... --> (j,k,j,k) (say) by examining the
> > > frequency distribution alone.
> >
> > I think we've established that the above is a
> > misunderstanding of the attack. In the first part of the
> > attack, a single block (two words) constitutes the entire
> > message. In the second part, the entire message is two
> > blocks (four words) in size. The attacker encrypts the same
> > short messages many times. He does not concatenate them
> > into one long message and encrypt at once.
> >
> > The probabilities given in the attack description refer to
> > encryption of the one-block (two-word) message and the
> > two-block (four-word) message.
>
> Thanks. It seems now that I am one step further in
> understanding you. Please keep on being patient with me.
>
> In the one block (u,v) case, through encrypting a few
> hundred times, one achieves that all possible combinations
> of permutations (assumed taking place with equal frequency)
> occur in the inter-cycle permutation processes. With 6
> such processes one gets 2^6 different kinds of ciphertext
> blocks of the type (a,b), each with equal frequency. Is
> that right?
>
> BTW, I don't understand why do you want to limit to 6
> and don't allow 7 permutation processes which is the
> actual situation. Does that cause difficulties to your
> attack?
Assume that there are N permutation processes. Then
this step generates 2^N blocks all distributed evenly.
>
>
> By the same argument, in the two block (u,v,u,v) case
> (with the same u and v as above) one gets 8^6 different
> kinds of ciphertext blocks of the type (c,d,e,f),
> again each with equal frequency. Is that right also?
No. That is where things go a little bit weird. Watch this simplified
example and see.
I shall use -> to indicate encryption, and => {....(x,y) 1/K ...} to
indicate possible permutation results(where (x,y) is the perm, and 1/K
is the probability.
(u,v,u,v) -> (a,b,a,b) => { (a,a,b,b) 1/6, (a,b,a,b) 1/6, (b,a,a,b) 1/6,
(b,a,b,a) 1/6, (b,b,a,a) 1/6, (a,b,b,a) 1/6}
so it would be 6^N th possibles distributed again uniformly.
Useful to note. 1/3of the time after a round your output is of the same
form as you input.i.e. (a,b,a,b) in (*,#,*,#) out.
then in 1/3^(N-1) of such cases you end N-1 rounds with an imput to the
next round of (x,y,x,y)->(x1,y1,x1,y1)=>
{ (x1,x1,y1,y1) 1/6, (x1,y1,x1,y1) 1/6, (y1,x1,x1,y1) 1/6, (y1,x1,y1,x1)
1/6, (y1,y1,x1,x1) 1/6, (x1,y1,y1,x1) 1/6}
Meaning that in 1^3^N cases you have an input to the last round of the
form. (x1,y1, y1,x1) which will output a message of the form
(x1,y1,y1,x1)->(x2,y2,m,n)=> which will be permuted prior to output.
since x2 and y2 and m and n should be familiar ( they are in the list of
2^N pairs that the 1 block encryption generated) you now know that{
(x2,y2) or (y2,x2)} and {(m,n) or (n,m)} are a special pair. This
allows the attacker to know that those two pairs are related up to round
N-1, and differ only on the last round. From there it is comparitively
simple to break a 2 round version of whatever is being used. since
birthday attacks can be done. this should work relatively fast. Thus the
effort needed in total is 4* the amount of effort needed to break a 2
round version of the cypher + the effort to achieve such a birthday
coincidence in the output.
>
>
> If both answers are yes, I don't yet see how you can
> utilize any frequency information in the ciphertext to
> guide establishing any set of equations. Could you please
> kindly explain?
>
> Thanks in advance.
>
> M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Reply-To: [EMAIL PROTECTED]
Date: Tue, 24 Oct 2000 21:56:39 GMT
John Myre <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> I believe the issue under discussion is what terminology is desirable -
:> not whether people understand the existing terms.
: Actually, those are the same. The only reason to change
: the "official" meaning would be because too many people
: don't understand it. [...]
I don't agree with that in the slightest.
...but this off-topic thread is too long as it is - please forgive me
if I now try to let it die gracefully.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Florist: Petal pusher.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Wed, 25 Oct 2000 01:02:33 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
[snip]
> > By the same argument, in the two block (u,v,u,v) case
> > (with the same u and v as above) one gets 8^6 different
> > kinds of ciphertext blocks of the type (c,d,e,f),
> > again each with equal frequency. Is that right also?
>
> No. The total number is higher than that, and they are not
> all equally probable. Fortunately for the attacker, the ones
> he's looking for are the most likely. They are the outputs
> for which the first five of the six permutations preserved
> block equality.
>
> Why are these the most probable? Because if the output of a
> permutation is two equal blocks, then the next random
> permutation has fewer possible outcomes.
>
> Let's look at a case reduced to two permutations (three block
> cipher cycles). We start with message (u, v, u, v). The
> cipher cycle always preserves block equality - the same input
> produces the same output. After the first cycle, we have (w,
> x, w, x).
>
> The permutation of (w, x, w, x) has six possible outcomes, all
> with probability 1/6. Two of these outcomes consist of two
> equal blocks (w, x, w, x) and (x, w, x, w), the other four
> have two distinct blocks. The second cipher cycle preserves
> block equality, but the four un-equal blocks will usually be
> mapped to texts of four distinct words (a, b, c, d).
>
> If the first permutation preserved block equality, then the
> last permutation receives a text of two equal blocks (x, y, x,
> y), and has six possible outcomes. If the first permutation
> did not preserve block equality, then the second permutation
> receives (a, b, c, d) and has 24 possible outcomes.
>
> There are thus twelve possible outcomes in which the first
> permutation preserved block equality - two possible outcomes
> from the first permutation, times six from the second. Each
> has probability 1/6 * 1/6 = 1/36. There are 96 possible
> outcomes in which the first permutation did _not_ preserve
> block equality. Four outcomes from the first, times 24 from
> the second. Each of those has probability 1/6 * 1/24 = 1/144.
> We can check that 12 * 1/36 + 96 * 1/144 = 1, as expected.
>
> That's a key insight to the attack: if the output of one
> permutation is two equal blocks, then the input to the next is
> two equal blocks and therefore the 24 possible permutations of
> four items produce only six distinct outcomes (two of which
> are also equal blocks). Of course that does not apply to the
> last permutation, since there is no "next" permutation.
>
> It is possible that the block cipher cycle could do something
> strange, such as map (a, b, c, d) to (e, f, f, e). I regard
> the probability of such things as negligible.
Thanks. I think that I now understand your frequency argument.
Following your three cycle (2 permutation) example, I'll
have the following. Please check whether I am right.
Input of first cycle (u, v, u, v)
Output of first cycle (w, x, w, x)
First permutation, preserving block equality, leading
to two possible outcomes (w, x, w, x) and (x, w, x, w)
Output of second cycle (l, m, l, m) and (j, k, j, k)
Second (last) permutation, arbitrary, giving rise to 6
each, of equal frequency, totalling 12, namely
(l, m, l, m) (j, k, j, k)
(l, m, m, l) (j, k, k, j)
(l, l, m, m) (j, j, k, k)
(m, l, l, m) (k, j, j, k)
(m, l, m, l) (k, j, k, j)
(m, m, l, l) (k, k, j, j)
Output of third cycle: (Ai, Bi, Ci, Di) and (Ei, Fi, Gi, Hi),
(1<=i<=6) totalling 12. This is the ciphertext.
Now please help again:
How am I going to set up the functional relations that are
useful for gaining information of the key? Can I simply
pick for this purpose any one of the 12 possible outcomes
of the ciphertext or only some particular ones? A previous
post of yours seems to require picking particular ones, but
I don't know how to recognize these, since all 12 are of
equal frequency.
Thanks in advance.
M. K. Shen
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: GCHQ Challenge
Date: Tue, 24 Oct 2000 23:11:57 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> Which was probably deliberate. Or at least, it would
> be quite sensible to have done it deliberately, given
> the purpose.
Yup, but if finding the bits is harder than working out what they mean
then does it really imply any sort of 'skill' at all?
More motivation I guess...
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Date: Tue, 24 Oct 2000 23:14:30 GMT
Tim Tyler wrote:
> Rob Warnock wrote:
> : You just *love* quoting stuff way out of context to twist
> : its meaning, don't you? [...]
>
> What an irritating post.
Perhaps, but if Warnock can irritate Tyler out of
misrepresenting a noted cryptographer's views, I'd say that's
worth doing.
> Stephen asked "Now what makes you think that he said it was
> breakable."
>
> I quoted the bit where he said he expected a break within five years.
No, that's not what he said.
> I didn't "twist the meaning". Bruce stated that he believes
> that within the next five years someone will discover an
> academic attack against Rijndael. That seems self-explanatory
> enough to me.
I cannot see how anyone with a clue about crypto could read
Schneier's piece without noticing how careful he was to _not_
say he expected a break. The statement defended with the
out-of-context quote, and especially the quote above beginning
"I quoted..." are misrepresentations of what Schneier said.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Discrete Log Question
Date: Tue, 24 Oct 2000 23:33:41 GMT
In article <[EMAIL PROTECTED]>,
Kent Briggs <[EMAIL PROTECTED]> wrote:
> Using the equation:
>
> y = g^x mod p
>
> we know that finding x is a hard problem when y, g, and p are known
(and
> p is a large prime). However, what if y, x, and p are known and you
> want to solve for g? Is that an equally hard problem?
No. It is trivial. You are asking to solve g^x - y = 0 mod p.
Cantor-Zassenhaus does this in milliseconds, even for 100 digit p.
See Knuth
--
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] (John Savard)
Subject: Re: SHA-384 and SHA-512
Date: Tue, 24 Oct 2000 23:58:24 GMT
On Fri, 20 Oct 2000 19:27:18 GMT, Daniel Leonard
<[EMAIL PROTECTED]> wrote, in part:
>BTW, why is it "128 bit" and not "128 bits" ?
For the same reason there is a "200-inch" telescope on Mount Palomar,
although the mirror is 200 _inches_ wide, or that stores offer for
sale a 19-inch TV set, with a diagonal across the picture of 19
inches.
When a unit of measure is used in this particular kind of adjectival
construction, it is singular in English.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Wed, 25 Oct 2000 02:14:42 +0200
Mok-Kong Shen wrote:
>
> Thanks. I think that I now understand your frequency argument.
> Following your three cycle (2 permutation) example, I'll
> have the following. Please check whether I am right.
.........
[snip]
I have after posting the above read the post of James Felling
who explained some of the points that were not clear to me.
You needn't answer to my previous post. I think I understand
now some of the essence of your attack and will be able to
proceed to study once again one of your previous post in
more detail, hoping to be able to capture it in full.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (H.Bruijn)
Subject: Re: I am after a simple one-way encryption algorithm
Date: 25 Oct 2000 00:31:18 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 24 Oct 2000 19:14:36 GMT, Tom St Denis allegedly wrote:
>In article <8t4klv$9jn$[EMAIL PROTECTED]>,
> "William Smith" <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> What is the simplest way to encrypt passwords using a one way
>> algorithm from a perl script. I wish to hold user passwords
>> in a data file which can then be used to validate passwords
>> which are entered.
>>
>> Any help appreciated.
>
>You don't want an encryption algorithm at all my friend.
What Tom so helpfully tried to point out is that you want something
called a cryptographic hash function. A cryptographic hash function does
make it extremely difficult to come up with a message that would hash
to a particular hash value. The MD5 Message Digest Algorithm is commonly
used, which produces hash values of 128 or more bits. This number is vastly
larger than the number of different passwords likely to ever be used in the
world.
[The MD5 alogirthm] takes as input a message of arbitrary length
and produces as output a 128-bit "fingerprint" or "message digest"
of the input. It is conjectured that it is computationally infeasible
to produce two messages having the same message digest, or to produce
any message having a given prespecified target message digest.
What you should do though is run MD5 over a string containing both the
username+password rather then just the password, since the MD5
fingerprints of two identical passwords would also be identical, and a
dead give-away for either one of the users.
It is specified in the internet Request For Comment 1321 and
which can be found at fi http://www.faqs.org/rfcs/rfc1321.html
And you can download the perlmodule here:
http://www.cpan.org/modules/by-module/MD5/
It was shown that MD5 is not collision-resistant, i.e., you can find
messages M, M', such that MD5(M)=MD5(M') faster than brute-force.
Although this is not a security problem per se, it is still something
a cryptographically strong hash function should not exhibit.
What is now recommended is the SHA-1 hash function. But MD5 is a much
faster algorithm so for a large number of applications it is still used.
Choose wisely,
Herman.
--
If a trainstation is the place where trains stop, what is a workstation?
========================================================================
Herman Bruijn mail: [EMAIL PROTECTED]
The Netherlands website: http://hermanbruijn.com
------------------------------
From: [EMAIL PROTECTED] (H.Bruijn)
Subject: Re: I am after a simple one-way encryption algorithm
Date: 25 Oct 2000 00:35:28 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 24 Oct 2000 19:14:36 GMT, Tom St Denis allegedly wrote:
>In article <8t4klv$9jn$[EMAIL PROTECTED]>,
> "William Smith" <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> What is the simplest way to encrypt passwords using a one way
>> algorithm from a perl script. I wish to hold user passwords
>> in a data file which can then be used to validate passwords
>> which are entered.
>>
>> Any help appreciated.
>
>You don't want an encryption algorithm at all my friend.
What Tom so helpfully tried to point out is that you want something
called a cryptographic hash function. A cryptographic hash function does
make it extremely difficult to come up with a message that would hash
to a particular hash value. The MD5 Message Digest Algorithm is commonly
used, which produces hash values of 128. This number is vastly larger than
the number of different passwords likely to ever be used in the world.
[The MD5 alogirthm] takes as input a message of arbitrary length
and produces as output a 128-bit "fingerprint" or "message digest"
of the input. It is conjectured that it is computationally infeasible
to produce two messages having the same message digest, or to produce
any message having a given prespecified target message digest.
What you should do though is run MD5 over a string containing both the
username+password rather then just the password, since the MD5
fingerprints of two identical passwords would also be identical, and a
dead give-away for either one of the users.
It is specified in the internet Request For Comment 1321 and
which can be found at fi http://www.faqs.org/rfcs/rfc1321.html
And you can download the perlmodule here:
http://www.cpan.org/modules/by-module/MD5/
It was shown that MD5 is not collision-resistant, i.e., you can find
messages M, M', such that MD5(M)=MD5(M') faster than brute-force.
Although this is not a security problem per se, it is still something
a cryptographically strong hash function should not exhibit.
What is now recommended is the SHA-1 hash function. But MD5 is a much
faster algorithm so for a large number of applications it is still used.
Choose wisely,
Herman.
--
If a trainstation is the place where trains stop, what is a workstation?
========================================================================
Herman Bruijn mail: [EMAIL PROTECTED]
The Netherlands website: http://hermanbruijn.com
------------------------------
From: "G. Orme" <[EMAIL PROTECTED]>
Subject: Re: idea for spam free email
Date: Wed, 25 Oct 2000 01:01:46 GMT
"Ben Clifford" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 21 Oct 2000 10:44:50 GMT, G. Orme <[EMAIL PROTECTED]> wrote:
>
> >> > In my opinion, filters installed on the receiver's e-mail software
are
> >> > still the best way to eliminate spam. Your sistem seems to be
designed
> >> > so that you will receive e-mail only from a list of sources you have
> >> > hand-picked. You can obtain the same result by writing a filter that
> >> > lets in only e-mail originating from a list of approved addresses.
> >
> >G. Your idea is very good. The system I am proposing is designed to
> >automatically do a similar thing so people using it don't need the hmmm
> >folder.
>
> But the whole point of the "hmm" folder is that it stores messages
> which could not be automatically decided upon.
G. The idea is that to send you email people have to download a small
program which does the encrypting. If they accept an agreement to not send
spam they can then freely use the network. If someone receives spam they can
complain and perhaps after a warning that person is kicked out of the
network. So you see anyone can send you anything, they just have to agree
first not to send you spam. A hmmm folder can be added for people who don't
accept the agreement though this would probably be all spam anyway.
>
> Therefore your program cannot automatically decide upon these
> messages, and would get them wrong 50% of the time.
>
> People have to have their own filtering systems based on what they
> want - if everyone runs the same filtering system, then spammers can
> rework their spam to get around this one filtering system. As it stands
> now, they cannot make spam which will pass every filtering system
> because filtering systems are so diverse.
>
> --
> http://www.hawaga.org.uk/ben/
> GPG key 30F06950 on key servers & my web page. You are encouraged to use
it!
> Visit my page for benno.globe - rotating world map applet.
------------------------------
From: Steven Wu <[EMAIL PROTECTED]>
Subject: Re: Finding Sample implementation for DES and IDEA
Date: Wed, 25 Oct 2000 00:48:02 GMT
In article <8t4l8l$jas$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8t45on$4nl$[EMAIL PROTECTED]>,
> Steven Wu <[EMAIL PROTECTED]> wrote:
> > Hi Jan,
> >
> > Thanks for your guide. I got the IDEA, but I still could not found
> DES
> > source on thoese sites. Could your like to help me again?
> >
> > -Steven
> > [EMAIL PROTECTED]
> >
>
> I wrote a sample DES implementation in C (ECB mode only), with some
> test vectors in the code. And because I wrote it, it's ugly, badly
> written, slow, uses too much memory, terribly inefficient,etc. of
> course :). But it works.
> http://www.geocities.com/WallStreet/Bureau/1195/des.c
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Thanks! But what is ECB ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Jerome A. Solinas" <[EMAIL PROTECTED]>
Subject: IEEE P1363 Meeting Announcement
Date: Tue, 24 Oct 2000 20:56:51 -0400
Reply-To: [EMAIL PROTECTED]
Study Group for Future Public-Key Cryptography Standards
IEEE P1363 Working Group:
Standard Specifications for Public-Key Cryptography
MEETING NOTICE
Wednesday, November 15, 2000, 8:30 am - 5:30 pm (study group and
new working group projects)
Thursday, November 16, 2000, 8:30 am - 5:30 pm (working group)
Friday, November 17, 2000, 8:30am - 5:30pm (working group)
National Security Agency
Fort Meade, Maryland
These meetings of the Study Group for Future Public-Key Cryptography
Standards
and P1363 working group are open to the public.
At the study group meeting, we will primarily discuss the P1363
Public-Key Techniques Registry. Hopefully a consensus can be
reached on whether the group wants to propose this project or not.
The group will entertain further presentations on future standards
work as needed and discuss the operation of the study group for
its lifetime. All attendees of this meeting are considered to be
full voting members of the study group.
At the P1363 working group meeting, we will review the latest draft of
P1363a in detail and work towards the completion of the draft standard.
The group will spend a fair amount of time attempting to address some
of the more difficult unresolved issues. We will discuss future plans
with P1363a, and directly related activities including starting work on
P1363b. The group will entertain presentations and discussions about
topics considered for P1363b and discuss the next steps for starting
that project. Please see the IEEE P1363 working group bylaws for
membership and voting procedures for the working group.
(http://grouper.ieee.org/groups/1363/)
The meeting will be hosted by the National Security Agency.
AGENDA
WEDNESDAY, NOVEMBER 15, 2000 8:30 am - 5:30 pm
Study Group for Future Public-Key Cryptography Standards and IEEE P1363
Working Group
1. Approval of study group agenda
2. Approval of August study group minutes
3. Discussion about P1363 Public-Key Registry
4. Discussion about other potential projects
5. Plan future work of the study group
6. Adjourn study group
1. Approval of working group agenda
2. Approval of August minutes
3. Officer reports
4. Update on status of new projects
5. New presentation to the working group (TBD)
6. Discussion about P1363.1 (outline, content, new format, timeline)
THURSDAY, AUGUST 24, 2000 8:30 am - 5:30 pm
Study Group for Future Public-Key Cryptography Standards and IEEE P1363
Working Group
NOTE: On Thursday morning, 9:00-10:30am, there will be a guided tour of
the
National Cryptologic Museum, which is adjacent to the meeting room.
6. Discussion about P1363.1 (cont� as needed)
7. Discussion about P1363.2 (outline, content, timeline)
8. Update on P1363a document
9. Update on related standards activities
10. Review of P1363a timeline
11. Discussion about major issues with P1363a
12. Detailed review of P1363a draft
FRIDAY, AUGUST 25, 2000 8:30 am - 5:00 pm
IEEE P1363 Working Group
12. Detailed review of P1363a draft (continued)
13. Discussion of continuing work on P1363b
14. Discussion of future activities of P1363 working group
15. Adjourn
MEETING FEE
There will be a meeting fee, which will be an IEEE fee of $10 per
half-day and an additional catering fee that will be split between
all attending (probably less than $20 per person). (subject to change)
MEETING LOCATION
The meeting will be hosted by the NSA at Fort Meade in Maryland.
Fort Meade is about 10 miles south of Baltimore Washington International
(BWI) Airport. Nearby hotels include:
Ramada Inn - BWI Airport
7253 Parkway Drive
Hanover, MD 21076
(410) 712-4300 or (800) 2-Ramada
Comfort Inn Airport
6921 Baltimore-Annapolis Blvd.
Baltimore, MD 21225
(410) 789-9100
Sheraton BWI Airport
Elm Rd.
(410) 859-3300
Columbia Inn
Wincopin Circle,
Columbia, MD
(410) 730-3900
REGISTRATION
Formal registration is not required. For planning purposes, please
RSVP to Ari Singer via e-mail at [EMAIL PROTECTED] or by phone at
(781) 221-1306 or to Jerry Solinas at [EMAIL PROTECTED]
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: How to post absolutely anything on the Internet anonymously
Date: 24 Oct 2000 18:02:06 -0700
zapzing <[EMAIL PROTECTED]> writes:
> I do not seriously harbor any hopes of preserving
> "our" political constitution. What is it about
> the present political system that you like, BTW?
If you're referring to the United States, what I like is that there
are established limitations on the powers of the government, which
they are not permittted to exceed, and which limitations cannot be
easily lifted. Of course, in practice they exceed those limits
fairly often, but the courts usually keep them mostly in line.
I think the direction of this thread is that when nanotechnology
becomes ubiquitous, protection of citizen's rights (especialy privacy,
a right not explicitly enumerated) will become all but impossible.
One would like to believe that nanotechnology might also provide
some potential solutions to the problem. However, it's very similar
to other security problems in that an attacker only needs to find one
hole to compromise your privacy, and no matter how much time/money/effort
you invest, there's no way to prove that you have privacy. You can
only disprove it.
------------------------------
** 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
******************************
