Cryptography-Digest Digest #244, Volume #12 Tue, 18 Jul 00 18:13:01 EDT
Contents:
Re: News about quantum computer (Bill Unruh)
Re: News about quantum computer (Bill Unruh)
Re: News about quantum computer (Bill Unruh)
Re: Has RSADSI Lost their mind? (Bodo Moeller)
Re: what is the symmetric algorithm for protection of classified info (Roger
Schlafly)
Re: stes-0.0.0 released (was: Steganographic encryption system) (lcs Mixmaster
Remailer)
Re: Carnivore and Man-in-the-middle ([EMAIL PROTECTED])
Re: what is the symmetric algorithm for protection of classified info by gov
agencies ? (Sundial Services)
Re: what is the symmetric algorithm for protection of classified info by gov
agencies ? (Jerry Coffin)
Re: Crypto analyze tool. ("Joseph Ashwood")
Re: Cryptographic Camouflage ("Joseph Ashwood")
Re: what is the symmetric algorithm for protection of classified (Tom Anderson)
Crypto source code library suggestions? (Kirk Ellett)
quantum cryptography ([EMAIL PROTECTED])
Re: Carnivore and Man-in-the-middle (Eric Smith)
Re: Has RSADSI Lost their mind? (Bodo Moeller)
updates : American companies can sell encryption products to ... (jungle)
Re: Crypto source code library suggestions? (Paul Rubin)
Cipher Block Chaining ("Vinchenzo")
Re: WSJ Article on Mexico / Encryption (jungle)
Re: Carnivore and Man-in-the-middle (Steve Rush)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: News about quantum computer
Date: 18 Jul 2000 16:25:39 GMT
In <[EMAIL PROTECTED]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
]Bill Unruh wrote:
]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
]>
]> >The German newspaper Computer Zeitung reported in its 13 July
]> >issue that a team consisting of US and German researchers
]> >has succeeded to synthesize a molecule that can store 5 qubits,
]> >while the best previous result was 3 qubits.
]>
]> ??? I do not know what this means. The record is 7 bits for an NMR
]> system.
]Could you give a reference? I would with that write a letter to the editor
]of the newpaper.
http://xxx.lanl.gov/abs/quant-ph/9908012
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: News about quantum computer
Date: 18 Jul 2000 16:29:25 GMT
In <[EMAIL PROTECTED]> Runu Knips <[EMAIL PROTECTED]> writes:
>According to c't 15/2000, p. 40, the best previous result was
>8 qubits, using rydberg-states (hope they have this name in
>english), while nobody has realized a quantum processor with
>5 qubits before.
?? Did you mean 3 rather than 8?
If this is via a non-nmr system (eg rydberg states of atoms, etc) then
this is much more impressive. The current year old best for nmr is 7
bits. Note, calling this a quantum processor is
a bit like calling an abacus a CPU.
( and what is c't 15/2000?)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: News about quantum computer
Date: 18 Jul 2000 16:31:58 GMT
In <[EMAIL PROTECTED]> Runu Knips <[EMAIL PROTECTED]> writes:
]In the german computer magazine c't, issue 15/2000 (from this monday),
]page 40 they say that the current record is 8 qubits, implemented with
]rydberg states of a single atom.
This makes no sense. 8 bits is 256 states.
I think the magazine has gotten itself very confused.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Has RSADSI Lost their mind?
Date: 18 Jul 2000 16:35:24 GMT
David Hopwood <[EMAIL PROTECTED]>:
>> Bodo Moeller <[EMAIL PROTECTED]> wrote:
>>> when the server reuses its DH key (which cannot be done with DSA-style
>>> parameters because of small-subgroup attacks),
> Am I not correct in thinking that it's OK to re-use DH keys iff it is
> checked that all transmitted group elements are of large order?
>
> For p = 2qR + 1 with q and R prime, that can be very cheap, since if
> y is a transmitted value, it's sufficient to check that 2 <= y <= p-2.
Parameters of this form should be harmless (just like safe primes,
or Lim-Lee parameters in general -- p = 2*q_1*q_2*...*q_k + 1 where
each of the primes q_i is large, e.g. over 160 bits); then you don't
need any special checks when reusing DH keys. However, for general
DSA-style parameters, you'd have to check not only that the order
of each transmitted element is large, but that it is exactly q.
It's the smooth part of p-1 that can be exploited for attacks.
When using DSA parameters, then checking that the order of an element
is 1 or q can be done by computing the (p-1)/q-th power of that
element and verifying that you obtain 1. But that's a 864-bit
exponentiation (for 1024-bit p and 160-bit q), so it's faster
to generate a fresh DH key for these parameters -- this requires
just a 160-bit exponentiation.
So if you use DSA-style DH parameters because these are fast to
generate, then you should not resue DH keys. If you are more patient
during DH parameter generation, then you can create parameters where
key reuse is not that much of a problem (in any case, it limits
forward secrecy [you cannot reuse the key unless you store it] --
but then, so does the SSL/TLS session cache).
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info
Date: Tue, 18 Jul 2000 10:54:37 -0700
"David A. Wagner" wrote:
> [nice list of secrecy arguments snipped]
> Finally, remember that there is some small but non-zero chance that
> publishing our cipher systems might just give our enemies the edge they
> need to break our systems.
Also, there is some chance that the enemies will see that the
systems are secure, and stop wasting the time of their smartest
guys on it, thereby freeing them up to do others that might be
disadvantageous from the NSA's point of view.
------------------------------
Date: 18 Jul 2000 18:00:02 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: stes-0.0.0 released (was: Steganographic encryption system)
[Newsgroups trimmed]
Phil Hunt writes:
> It's on the web at <http://www.comuno.com/linux/stes/stes-0.0.0.tgz>.
>From the README file:
: How it works
: ------------
:
: The ciphertext file has two parts -- a Check Area (CA) and a Data Area (DA).
: The DA actually holds the data and the CA tells stes which bits of the DA
: are associated with each key.
:
: The DA is split up into 50 Data Items (DIs).
:
: The CA is split up into 30 Check Items (CIs). Each CI contains:
:
: - three 32-bit check numbers
: - the length in bytes of the data associated with this key
: - a bitmap which defines which DIs hold the data for this key
:
: The 3 check numbers (check1..check3) are multiples of 3 numbers
: (mult1..mult3).
:
: When decrypting according to a key (k), the system will attempt to decrypt
: each CI with that key. If the decrypted check values are found to be
: multiples of mult1..mult3 respectively, then the system knows that the key
: matches that CI (there's a 10^-12 probability of a false positive).
:
: Once a matching CI is found, the decryption program can read the rest of
: the CI: it knows the size of the data, and which DIs hold it. (It is stored
: from the lowest numbered DI upwards), so it can decrypt them with the key
: and reproduce the data file,
The check number mechanism seems slightly cumbersome. It would be more
straightforward just to put a fixed value there. Some people will whine
about known plaintext, but let's get serious: known plaintext is not
a problem with a strong cipher. The cheapest way to break this kind of
system is by torturing the key holder, not by looking for known plaintext.
No significant security weakness would arise by using a fixed check
number to recognize proper decryption.
The system can hold only a fixed number of separate files, 30 in this
case. I thought you might have something more elegant in mind that could
handle an unlimited number of files. You didn't say anything about this
limit in your earlier description.
There is a limit of 50 DIs, and the header file says that DI size is 1K.
Does this mean that you have a limit of 50K of data stored? This would
also seem to be an unfortunate limitation.
One possible weakness would arise if the attacker, by examining your
disk, found earlier deleted copies of the ciphertext file. Looking at
differences between those copies and the current one, they could see which
segments had been updated, and demand that you produce the key for those
parts. This would defeat your goal of producing only unimportant keys.
Over time, with repeated updates, DI leaks will occur. When you put a
file in, and then update it with a shorter file, the DI's allocated to
the longer version will be lost and never be usable again. This may be
a bug or a feature, depending on how you look at it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Carnivore and Man-in-the-middle
Date: 18 Jul 2000 17:19:32 GMT
Once upon a time, "dlk" <[EMAIL PROTECTED]> said:
>
>[EMAIL PROTECTED] wrote in message ...
><snip>
>>Subsituting packets would be feasible (I wouldn't say trivial), but
>>defeating the underlying encryption schemes would be impractical.
>
>Why? Or rather, who says that the Carnivore sys would have to
>perform the processing? *Assuming* that it can function as an
>interceptor (vs a simple monitoring tap), why not do a "hold and
>re-direct" method: send the stored stream (from a specific node)
>to some other nice and fast machine for processing, receive the
>altered result and then transmit that?
When I initially thought about it, it seemed to me that the
individual Carnivore systems could be "prestocked" with several
thousands of pre-calculated private/public key pairs. Recognizing
public keys transmitted on the line might be troublesome, but
swapping them, once recognized, for keys from the internal list
would be a very trivial task (*IF* Carnivore systems have the
potential for such swapping; that is not yet clear to me. Elleron
says it would be feasible, but doesn't explain how).
After that point, recognizing an exchange of public-key-encrypted
session keys and replacing them with (again, precalculated) session
keys encrypted by the adversary's key would be a similar ordeal --
the harder half of the problem would be recognizing the exchange,
not replacing the user's exchange with an adversary's exchange.
At first I thought that a central repository of keys would be
necessary for the various Carnivore nodes to synchronize (ie, know
what's a user's key, and what is a Carnivore-swapped key), but just
now I realized that as long as the keys are going to be precalculated
anyway, there's no reason each Carnivore system couldn't start its
life with a complete database of all Carnivore keys, with a narrow
slice of them dedicated to its own use (only this slice would need
to have private key parts or precalculated session keys, so a
globally coherent database of public key parts would only eat about
a gigabyte per few *million* keys). I'm trying to think of another
reason that Carnivore might need to send or receive data off-site,
but I can't think of one right now.
>Depends upon the 'strength'
>of the crypto used but methinks <56 bit symmetric or "flawed"
>implementations of >56 bsym might just be "doable",
>not in honest-to-goodness real time of course, but I don't
>think we'd be talking days of delay either.
It is my understanding that the Man-in-the-Middle attack works
independently of the strength of the keys involved, but I might
be missing something. How do you mean that it depends upon the
strength of the crypto used, and why couldn't the key-swapping be
done in real time?
-- TTK
------------------------------
Date: Tue, 18 Jul 2000 11:23:54 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by gov
agencies ?
It's probably more of a question of "need to know." I mean, you can
more-or-less assume there IS a spy and that the information IS known,
but why publish it? NSA would increase the risk by some non-zero amount
and profit nothing thereby ... so why?
>Roger Schlafly wrote:
>
> "David A. Wagner" wrote:
> > [nice list of secrecy arguments snipped]
> > Finally, remember that there is some small but non-zero chance that
> > publishing our cipher systems might just give our enemies the edge they
> > need to break our systems.
>
> Also, there is some chance that the enemies will see that the
> systems are secure, and stop wasting the time of their smartest
> guys on it, thereby freeing them up to do others that might be
> disadvantageous from the NSA's point of view.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by
gov agencies ?
Date: Tue, 18 Jul 2000 12:24:34 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> are you saying that obscurity is the security used for protection of classified
> info by gov agencies ? instead of the cipher strength ?
Not "instead of", but "in addition to". Every indication is that the
NSA can design ciphers very well, and that the ciphers they design
have almost _exactly_ the strength they're designed to.
However, assume even the best case: you've obtained (somehow or
other) a dozen or so chips containing a secret encryption algorithm.
It might easily take a year and a million dollars JUST to figure out
exactly what the algorithm IS. In addition, much of the time and
effort involved requires people with almost entirely different skills
than cryptanalysis.
These two factors are likely to filter out any but the very most
serious attackers from even making an attempt. Even in those cases,
the secrecy adds substantial time and effort to the job.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Crypto analyze tool.
Date: Tue, 18 Jul 2000 11:29:40 -0700
> >> >doesn't work (RSA is secure with 1 round, DES takes several), you
can't
> >> >judge them on size (a Vigenere cipher can be gigabytes in size and
still
> >be
> >> >weak...
> >>
> >> What do you mean by "a Vigenere cipher can be gigabytes in size:" the
> >> Vigenere key? How do you propose breaking a Viggy that uses a key
> >> of that size?
> >
> >Known plaintext attack?
>
> Yeah, that should do it. I was wondering, however, whether
> Ashwood thought a Vigenere with such a huge key was
> vulnerable to a ciphertext-only attack.
I'm quite sure that it is vulnerable to a ciphertext-only attack, but I
certainly wouldn't want to attempt one, too much data to deal with.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Tue, 18 Jul 2000 11:42:32 -0700
Unfortunately I need to correct one of the statements I made in this thread,
apparently I'm not supposed to refer to the camouflage as encryption
(although my standard definition applies*), so the actual obfuscation of the
key is performed as:
ENCRYPT(e, ServerKey)
camouflage(d, PIN)
Joe
* My standard definition for cryptography is (editted for content) "The art
of [messing] [data] up so that no one else can un[mess] it" (originally
stated by a friend of mine without content editting)
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified
Date: Tue, 18 Jul 2000 20:02:47 +0100
On Tue, 18 Jul 2000, Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> > are you saying that obscurity is the security used for protection of classified
> > info by gov agencies ? instead of the cipher strength ?
>
> However, assume even the best case: you've obtained (somehow or
> other) a dozen or so chips containing a secret encryption algorithm.
> It might easily take a year and a million dollars JUST to figure out
> exactly what the algorithm IS. In addition, much of the time and
> effort involved requires people with almost entirely different skills
> than cryptanalysis.
IOW, they get security by mixing operations from different groups, a
well-known technique in cryptography :).
tom
------------------------------
From: Kirk Ellett <[EMAIL PROTECTED]>
Subject: Crypto source code library suggestions?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jul 2000 19:17:28 GMT
Hello,
I am in need of a non-platform dependent encryption library in ANSI C
source code. I only need conventional strong encryption/decryption, not
public key, key management, or compression. The most important
requirements for my project are speed and a generic code base, one not
dependent on any libraries other than standard C. I also need it in a C
library API format, not a standalone executable. Can anyone point me to
any publicly available code legal for use in the US?
Kirk
------------------------------
From: [EMAIL PROTECTED]
Subject: quantum cryptography
Date: Tue, 18 Jul 2000 20:01:33 GMT
Anyone that's interested, here's a decent book on quantum cryptography.
Go to chapter 8. "The Code Book: The Evolution of Secrecy From Mary
Queen of Scots to Quantum Cryptography", by Simon Singh.
public key at idap://certserver.pgp.com ([EMAIL PROTECTED])
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: Carnivore and Man-in-the-middle
Date: 18 Jul 2000 13:49:41 -0700
[EMAIL PROTECTED] (phil hunt) writes:
> Perhaps. IMO it's more likely that our generation will be the first to
> know total freedom of speech.
Total freedom of private speech, maybe. Public speech with anonymity,
they're doing everything in their power to eliminate. Perhaps things like
Freenet (freenet.sourceforge.net) will work to preserve our rights in
this area, or perhaps the government will manage to shut such things down
(under the guise of protecting artists).
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Has RSADSI Lost their mind?
Date: 18 Jul 2000 20:06:40 GMT
Bodo Moeller <[EMAIL PROTECTED]>:
> David Hopwood <[EMAIL PROTECTED]>:
>> [...] p = 2qR + 1 with q and R prime [...]
> Parameters of this form should be harmless (just like safe primes,
> or Lim-Lee parameters in general -- p = 2*q_1*q_2*...*q_k + 1 where
> each of the primes q_i is large, e.g. over 160 bits); [...]
I assumed that R is a large prime. If R is small, then
see David Wagner's article.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: updates : American companies can sell encryption products to ...
Date: Tue, 18 Jul 2000 17:30:19 -0400
on monday 17/07/2000 ...
The Clinton administration also announced Monday updates to its export
control policy for powerful data and voice-scrambling technology.
===================
Under the
change, American companies can sell encryption products to any end user
in the European Union or these eight other trading partners: Australia,
Norway, Czech Republic, Hungary, Poland, Japan, New Zealand and
Switzerland.
===================
The policy change will also remove a previous technical review
waiting period of 30 days.
read full info at
http://www.cnn.com/2000/TECH/computing/07/17/clinton.wiretaps.ap/index.html
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Crypto source code library suggestions?
Date: 18 Jul 2000 21:31:58 GMT
In article <[EMAIL PROTECTED]>,
Kirk Ellett <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I am in need of a non-platform dependent encryption library in ANSI C
>source code. I only need conventional strong encryption/decryption, not
>public key, key management, or compression. The most important
>requirements for my project are speed and a generic code base, one not
>dependent on any libraries other than standard C. I also need it in a C
>library API format, not a standalone executable. Can anyone point me to
>any publicly available code legal for use in the US?
You don't say what ciphers you want, etc., but simplest is probably
use the conventional encryption libraries from OpenSSL
(www.openssl.org). Everything you want is almost certainly there.
------------------------------
From: "Vinchenzo" <[EMAIL PROTECTED]>
Subject: Cipher Block Chaining
Date: Tue, 18 Jul 2000 17:20:03 -0400
I would like to know how to decrypt a message encrypted with a block algo
(IDEA) mixed with the CBC (cipher block chaining) method?
I understood that for the encryption you must initialize a vector 'v' and
then xor it with my first block of plain data before encrypting the result
with the block algo. After I display the result of the encryption and I xor
it with the next block...etc...
Now if I have all the encrypted block and the initial vector how should I
decrypt the message?
Thanks
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: WSJ Article on Mexico / Encryption
Date: Tue, 18 Jul 2000 18:04:29 -0400
http://www.wired.com/news/politics/0,1283,37337,00.html
Mexico Race Hinges on Code Crack by Mike Kamber
3:00 a.m. Jun. 30, 2000 PDT
MEXICO CITY -- Just days before an election that threatens to end the 71-year
rule of Mexico's Revolutionary Institutional Party (PRI) computer hackers and
encrypted CD-ROMs have become key factors in Sunday's ballot.
Many here believe the CD-ROMS will reveal a tangled web of alleged election
fraud, drug trafficking, and most importantly, corruption tied to the lending
practices of Mexico's banks in the early 1990s.
Billions of dollars went to corporations and wealthy individuals supporting
the PRI, which obtained millions in direct loans to finance its 1994 political
campaign.
But later that year, inflation rose and the defaults began.
The PRI-dominated congress created a fund to help Mexico's banks weather this
"small financial crisis." The fund assumed repayments only on the largest
loans, those owed by corporations, leaving smaller debtors accountable in full.
Fobaproa, as the scandal came to be known, today amounts to a US$4.5 billion
dent in Mexico's budget. Critics have missed no opportunity to remind voters
that 2.5 million Mexicans working full time at the country's $3.50-a-day
minimum wage would take 35 years to repay the Fobaproa debt.
Thus, it is no wonder the CD-ROMs now referred to by one and all as "the
famous CDs" and their elusive contents are the stuff of speculation because
many Mexicans don't believe the PRI -- the only party that has ever ruled their
country -- will give up power easily.
The Revolutionary Democratic Party (PRD), running a distant third in the polls
despite the efforts of its candidate, Cuauhtemoc Cardenas, had little to lose
when it hired hackers to crack the encryption.
It was a calculated decision. Many Mexicans live on as little as $30-a-month
in villages without electricity. If the PRD can de-encrypt the CD-ROMs and
implicate rival politicians before the election, Cardenas and his party are
convinced the resentment of poor voters could change the course of Mexican
political history.
Opening the encrypted CD-ROMs requires six passwords. There is one for each of
Mexico's five political parties and a sixth that belongs to a Canadian auditor,
Michael Mackey, hired by Mexico's congress to conduct an external audit of the
bailout. Mackey's results, encrypted passwords and all, are on the famous CDs.
According to Delores Padierna, a PRD politician involved in the hacking
effort, the PRI also has Mackey's audit results on an unencrypted disk. But the
PRD doesn't, and as of now, the hackers, dubbed "technicians" by the party,
have cracked all but the PRI password in a high stakes race to the polls.
At PRD headquarters, Hilario Juarez Trejo, the party's computer coordinator,
is at once knowledgeable and cagey when asked about the party's efforts.
"The one we don't have contains 11 characters -- eight letters and three
numbers," he said. "So there are millions of combinations -- it could take time
to find it."
And as the election draws nearer, Padierna worries more.
"We know that they are opening the unencrypted CD-ROMs all the time," says
Padierna. "Not only are they reviewing them, but they are modifying and
deleting data."
Her fear is that newly modified data will be burned onto a CD and presented by
the PRI as original, making the hackers' efforts that much more important for
Mexico's future.
"Publishing the contents of the CDs could change the outcome of the
elections," says PRD Congressman Ramirez Cuellar, "because (Francisco
Labastida), the presidential candidate of the PRI, would be implicated."
Now, the PRI is threatening legal action if the PRD goes public with the
contents of the CD-ROMs, claiming that would violate the lenders' fiduciary
responsibilities.
Ramirez Cuellar laughs at the thought. "Fobaproa is the robbery of the
century, maybe the biggest in Mexican history," he said. "The banker's secrets
are the secrets of delinquents."
Nomen Nescio wrote:
>
> Did anyone catch the front page of the Wall Street Journal
> yesterday (7-13-2000). They mentioned in a follow up article
> that the 'leftist' party had cracked the encryption on a report
> that had come into their hands from the ruling party detailing
> who got paid off in some bailout.
>
> There had been an earlier article, several weeks ago that the
> decryption was being attempted.
>
> Does anyone know any more details about this?
------------------------------
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: Carnivore and Man-in-the-middle
Date: 18 Jul 2000 22:09:32 GMT
>Yes, but the original assertion that a canivore unit will be
>permanently installed in every ISP's data path is something I haven't
>heard before. (And tend to doubt ;)
>
>Granted, the entire system has some serious issues to be resolved, but
>paranoia cerainly won't help.
>
Given that every ISP has to be connected through some point-to-point broadband
link (Are there still any ISPs using dialup ISDN?), the Carnivore box wouldn't
have to be on the ISP's premises. Just stick it on the other end of the link,
and prohibit the broadband carrier from telling the ISP owner that he's being
monitored.
This sounds like a trivial variation on the proposal to equip all telephone
central offices with hardware that would allow the FBI to monitor any telephone
line by remote control. AFAIK, that one is already in progress, if not
complete.
Of course, these devices would be activated on a particular line only with a
court order. Our government would no more conduct a nationwide,
unconstitutional snooping operation than it would inject unsuspecting hospital
patients with plutonium salts, or allow war criminals to get away with their
crimes in exchange for their data.
==========================================================================
==============
If it's spam, it's a scam. Don't do business with Net abusers.
------------------------------
** 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
******************************
