Cryptography-Digest Digest #879, Volume #13 Tue, 13 Mar 01 04:13:01 EST
Contents:
Re: Text of Applied Cryptography .. do not feed the trolls ("Douglas A. Gwyn")
Re: Noninvertible encryption (David Schwartz)
Re: An extremely difficult (possibly original) cryptogram (David Schwartz)
Re: Super strong crypto (Benjamin Goldberg)
Re: NTRU - any opinions (Benjamin Goldberg)
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Super strong crypto (Mok-Kong Shen)
Re: Text of Applied Cryptography .. do not feed the trolls (Mok-Kong Shen)
Re: OverWrite: best wipe software? (Dan Hargrove)
Re: Text of Applied Cryptography .. do not feed the trolls (Paul Schlyter)
Re: Text of Applied Cryptography .. do not feed the trolls (Paul Schlyter)
Re: GPS and cryptography (Paul Schlyter)
Re: Text of Applied Cryptography .. do not feed the trolls (Paul Rubin)
Re: Encrypt then HMAC or HMAC then Encrypt? (Mark Currie)
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Noninvertible encryption (Mok-Kong Shen)
Re: => TV detection (was: FBI easily cracks encryption ...?) (Thomas Shaddack)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 07:08:45 GMT
Paul Rubin wrote:
> I replace my computer so often whether or not I download a
> particular file.
Since it's about statistics, it's about policy, not isolated
incidents. If you are not in the habit of perusing documents
on a computer you might not be inclined to replace it as often..
> A lot of the rent I'm currently paying is basically to have space
> for the books. A fair amount of energy is used to heat that space
> in the winter.
Ah, but think of the R-value of bookcases lining the walls.
> The CD-rom is 0.5 ounces of plastic with gunk sprayed on it.
Yeah, and manufacturing, packaging, distribution, etc.
> Can you seriously think the energy trade-off favors paper?
Perhaps, because sunlight is essentially free whereas using
petrochemicals deplete relatively scarce resources.
(However, plastic is a better use of them than for fuel,
which is used in *both* manufacturing chains. As I said,
it isn't a simple trade-off.)
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Mon, 12 Mar 2001 23:07:32 -0800
"Douglas A. Gwyn" wrote:
> Precompression does (at least) *two* things: it reduces the
> expected CT size (trades off the cost of extra computation
> for effective throughput), and it reduces redundancy, which
> makes methods of C/A that rely on statistics less effective.
> D.Scott is concerned primarily with security, not throughput,
> and his concern about standard compression methods, as I
> understand it, is that they often concentrate some of the
> redundancy at the start of the CT instead of spreading it
> evenly throughout the entire CT. That is worth worrying
> about if security is your prime concern, although my own
> opinion is that it is not a big enough flaw to be exploited
> by practical C/A for most likely systems.
You either trust your encryption or you don't. IMO, the uncomprsesed
data is _much_ more likely to contain vulnerabilities than the
compressed data is.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Mon, 12 Mar 2001 23:44:27 -0800
daniel mcgrath wrote:
>
> Tysoizbyjoxs, this may be the most complicated code anyone has ever
> done!
>
[snip]
> I do want to see some comment, even if you are totally lost, as no
> doubt quite a few of you are.
I'll make a deal with. I'll decrypt your message if you can decrypt
mine.
The ciphertext is:
X
To make it easier, I'll give you an example ciphertext and plaintext
using the same cipher _and_ the same key.
Ciphertext:
Y
Plaintext:
Now is the time for all good men to come to the aid of their party.
Good luck.
DS
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 07:56:47 GMT
Joe H. Acker wrote:
[snip]
> Suppose there are only 3 candidates {Peter, Steve, James} in question
> for Bob. Then the question can be reduced to a finite set of yes-no
> questions:
>
> Bob: Was Peter at the British embassy yesterday at 15 PM?
> Bob: Was Steve at the British embassy yesterday at 15 PM?
> Bob: Was James at the British embassy yesterday at 15 PM?
>
> The informational content provided by Alice answering "Peter" should
> be 3 bits *given the assumption of Bob that there are 3 candidates*.
> Defining quantified informational content that way makes it dependant
> on Bob's state of belief.
Actually, that should be two bits, not three, since at most two
questions actually need to be asked, if there are only three candidates,
and if one and only one of them at a time can be at the embassy.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Tue, 13 Mar 2001 08:01:21 GMT
DJohn37050 wrote:
>
> ECC is very suited to constrained environments, having short keys and
> sigs and simple key gen. It is not cleat at all to me that NTRU is as
> suited as it has longer keys than even RSA, longer sigs than RSA, not
> studied key gen yet but I do not see how anything can be simpler than
> ECC. It seems to be faster than RSA on NTRU's implementations but
> they also seem to say that ECC SigGen is slower then SigVer which does
> not compute.
> Don Johnson
ECC keygen is fast, but only if you already have a curve selected. If
you need to generate a curve, too, then it's damn slow.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 09:05:26 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98k9uf$6c6$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >"Explicit" PCFB mode decryption and authentication algorithm as it might
be
> >implemented in a "crypto engine".
> >
> >Input: Cipher text C, a stateful pcfb mode decryption function D, a
format
> >specifier string F.
> >Output: Parsed plain text structure P, a value true or false.
> >
> >1. T := D(C)
> >2. P := Parse(F,T)
> >3. If P is not empty, return(True), otherwise return(False).
>
> Is the format specifier F supplied by the application?
> If so, I'm not very happy with this design. Such a design
> provides no assurance that the format will contain sufficient
> redundancy to prevent forgery attacks. In practice, it might,
> or it might not. When security is at stake, the system should
> rest on a firmer foundation than this.
Yes, the format specifier ought to be supplied by the application. I thought
about the redundancy aspect too, and there are three ways to deal with it:
Firstly, the redundancy might be made sufficient by necessity through syntax
constraints, e.g. by limiting the domain of wild cards and the minimal
length of each template. If a message lacks sufficient redundancy, it is
added by the corresponding encrypt function (e.g. in the form of trailing
blanks). Secondly, the redundancy might be calculated by the Parse function
and compared to a hard coded constant limit. Formally speaking, these
methods are equivalent, but the former has better performance and the latter
is more flexible. In both cases an exception is raised if an invalid format
specifier is passed to the function. Such exceptions should be discovered by
the developer whilst debugging. The third solution is to let the developer
be responsible to measure the redundancy at design time. Utilities could be
provided for this purpose. Ultimately it should be possible to switch
between the three modes by setting compiler directives.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 09:02:55 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > My point is essentially the following: If one can define and
> > quantify 'propagation of information' (rigorously), then
> > one must be able to measure the information content in
> > an arbitrarily given bit sequence in exact terms.
>
> But that's wrong. Information is inherently contextual (relative);
> it does not inhere in individual, out-of-context bit values.
> A given bit sequence might or might not convey information,
> depending on one's expectations. E.g. if you expect to receive
> a 0 bit and someone sends you a 0 bit, you do not receive "1 bit"
> of information (more nearly 0 bits, depending on how strong your
> a priori expectation is).
But the original issue is to study 'propagation of
information', isn't it? If there is no information at the
start, then there can also be no propagation, right? So, if
there is a case where you can claim to be able to study the
propagation of information, there must be some information
at the start, at the end and in all intermediate stages
(the information may be of different quantity at different
points, being lost or augmented or whatever) and that
information must be exactly quantified, if your study is
to be formal and rigorous as you wanted. And that brings
back to my argument precisely.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 09:20:00 +0100
Paul Rubin wrote:
>
[snip]
> A lot of the rent I'm currently paying is basically to have space for
> the books. A fair amount of energy is used to heat that space in the
> winter. I value the data in them enough to not want to throw them in
> the trash, but if I could have them in digital form, I'd be a lot more
> mobile, would need less living space, lower energy consumption, etc.
The e-books are coming. I think it wouldn't be difficult
to also allow the reader to put notes on the pages or
do underlining etc., as such is already possible in other
documentation systems.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Dan Hargrove)
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: 13 Mar 2001 08:22:17 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in
<[EMAIL PROTECTED]>:
>
>
>William Hugh Murray wrote:
>>
>> Mok-Kong Shen wrote:
>>
>> > Benjamin Goldberg wrote:
>> > >
>> > [snip]
>> > > If I've got data on a floppy, and I want it securely erased, I
>> > > copy the stuff I want to save to a new floppy, and burn the old
>> > > one. Floppies are cheap. The cost of buying new floppies is
>> > > lower than the security risk of downloading binaries from your
>> > > website.
>> >
>> > Removable media, since they are now all quite cheap, should
>> > be physically destroyed for preventing recovery. For hard
>> > disk drives there are firms specialized in recovering deleted
>> > data.
>>
>> Yes, there are but hard drives are cheap too. The first hard drive I
>> ever purchased cost me $3K- for 10Megs. The first one I ever sold was
>> thousands of dollars per meg and was the size of a refrigerator.
>> Today I can buy 100Gigs for the same price with a computer thrown in.
>> How cheap must a drive be for one to recommend its destruction? Seems
>> to me we have passed the threshold. If the value of the residual data
>> is so high that someone might be willing to pay a lab to recover it,
>> then a few whacks with a sledgehammer or running it over once or twice
>> with one's SUV seems like a good investment. Make the calculation in
>> terms of the replacement cost of the drive, not its original purchase
>> price.
>
<snip>
>I conjecture that with a really effective program (i.e.
>one that the maintenance and repair people use and that
>can address all sectors of the disk) to overwrite a dozen
>or more times with differing bit patterns would render
>recovery beyond the capability of current technology. But,
>of course, physically destroying the hard drives certainly
>provides more confidence for the user and, as you pointed
>out, could well be afordable at current hardware prices.
>
>M. K. Shen
>
I would refer you to the following page.
http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
I hope this clarifies things for you.
Regards;
Dan
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: 13 Mar 2001 08:20:58 +0100
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
>"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>> Tom St Denis wrote:
>> > Don't give me that dead tree crap.
>>
>> Not only are trees renewable resources, and paper printing
>> technology much more highly developed and easier on the eyes
>> than computer-based documents, but also it takes quite a
>> lot of *non*renewable resources to make a computer.
>
>Yeah, but I already have a computer. Are you saying it's going to use
>more resources for me to download a few megabytes of electrons than to
>print several pounds of paper and get someone put the printout on a
>fossil-fuel-burning airplane and have it delivered to me?
Do you really expect to never upgrade your computer?
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: 13 Mar 2001 08:24:30 +0100
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>> more resources for me to download a few megabytes of electrons than
>> to print several pounds of paper and get someone put the printout
>> on a fossil-fuel-burning airplane and have it delivered to me?
>
>The exact trade-off computation could be made, but it's more complex
>than even that. You replace your computer every so often, and it
>required electricity to operate, etc. but then you *might* use
>electricity when reading a book, and so it goes. My point was that
>it is not so simple as just thinking "book => dead tree".
In particular since paper can be resued too! Books, newspapers, etc
which are thrown away can be recycled into paper used for printing
new books/papers.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: GPS and cryptography
Date: 13 Mar 2001 08:25:57 +0100
In article <98k24o$[EMAIL PROTECTED]>,
Ben Cantrick <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, br <[EMAIL PROTECTED]> wrote:
>> What do you think about using Global Positionning System (GPS) as key to
>> encryption?
>
> Keyspace is too small. GPS isn't hideously exact. Even combining
> lat, long and elevation you're not going to get a lot of bits to work
> with. Brute-force sweeping of the key space looks like a very likely
> possibility.
If we assume a GPS accuracy of 5 meters, this would yield a keyspace
of about 44 bits. Now, 3/4 of the Earth is ocean, and a lot of the
remaining 1/4 land areas are wilderness areas (Antarctica, Siberia,
Greenland, Sahara, etc) - remove that and we'll end up with a key
space of less than 40 bits. Here I've disregarded elevation since if
we assume ground level, elevation can be read off a topographic map
anyway. If we assume the GPS receiver would ride in an airplane
capable of climbing up to 10,000 meter (assuming a vertical accuracy
of 15 meters; most GPS receivers are less accurate in the vertical
direction) we would get 9 additional key bits; if we assume a
Concorde capable of climbing twice as high we'd get one additional
key bit.
All these alternatives would yield fewer key bits than Single-DES,
and Single-DES is considered insecure because it has too few key bits...
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: 13 Mar 2001 00:26:46 -0800
[EMAIL PROTECTED] (Paul Schlyter) writes:
> In particular since paper can be resued too! Books, newspapers, etc
> which are thrown away can be recycled into paper used for printing
> new books/papers.
Yes, and paper recycling uses a lot of energy, plus creates a lot of
incredibly nasty pollution.
Bits good, paper bad.
------------------------------
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 13 Mar 2001 08:25:57 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>I am storing an encrypted data packet. Typically small (less than 1K
>FWIW). I am encrypting the data, then taking an HMAC of the encrypted
>data plus other plain text data. The HMAC is appended to the plain text
>data and cipher text data over which it operates on.
>
>I know SSL takes an HMAC of data then encrypts everything including the
>HMAC. I can't see anything really definitive that would say that one
>method is better over the other?
>
>Can someone please give me some good reasons to pick one way vs the
>other?
>
>Thank you.
>
>Bjorn Forsberg
Hi,
Here a few reasons:
AUTHENTICATION:
An HMAC is a keyed digest and it therefore provides data integrity and
authentication. If you encrypt then HMAC and you use the wrong key to decrypt
the message, you will have already satisfied the integrity and authentication
rules on the receiver, even though you actually have garbage data. You
therefore would have to add an additional field in the clear text to cater for
the clear text integrity.
STORAGE:
If you wanted to store the messages for later authentication, you would have to
store the entire encrypted message + HMAC + encryption key + HMAC key. If you
also need to store the plain text, you need twice the database size. Whereas
the other way around you only need the plain text + HMAC + HMAC key.
KEY MANAGEMENT:
You should generally try to separate the integrity and authentication key from
the cipher key as the cipher key may be used for other message types or cipher
operations. If you store the cipher key with the HMAC key for a long term, you
may be affecting the long term confidentiality of other operations.
In general, you should always do the integrity and authentication operation on
the clear text before encryption. That way you are signing the real content
that you want to authenticate.
Mark
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 09:32:35 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98jta5$3hf$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >1. I am not sure I understand what you mean by "implicit". Yes, the check
> >might be intertwined with other processes the application would do
anyway.
>
> Here's what I mean by "implicit". If the ciphertext was inauthentic,
> the crypto layer will pass up garbled plaintext, and hope that the app
> will discard this when some sanity check fails (e.g., that some reserved
> bits which should be zero aren't zero, or somesuch).
>
> I don't believe, even for a second, that "implicit authentication" might
> have a significant performance advantage over "explicit authentication".
> The cost of a conditional branch is orders of magnitudes less than the
> cost of decryption. Have you benchmarked the difference? I strongly
> doubt that you'll be able to find any non-negligible performance
difference
> between the two approaches.
No, CPU time is not a major issue. If you use a CBC mode cipher and a
CBC-MAC based on the same cipher, this combination will run at practically
exactly the same speed as PCFB-m/n mode where n = 2m. However, there are a
couple of other differences: (a) In the former case you need two IVs and two
keys, in the latter case you only need one of each. (b) If the
authentication relies on the redundancy of the format of the message rather
than on some sort of padding, then PCFB does not increase the band width. As
Scott Fluhrer said, this might be an interesting feature in case of disk
sector encryption (although I must admit I hadn't thought about that myself,
wasn't this Paul Crowley's idea?), but also for high traffic client server
systems where the messages or packets are too short to be successfully
compressed using standard techniques (put together the MAC and the
compression header will add at least as much band width as the actual
compression subtracted), but still contains sufficient redundancy for a
format check to get a reasonable grip.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Tue, 13 Mar 2001 09:34:27 +0100
"Douglas A. Gwyn" wrote:
>
> Precompression does (at least) *two* things: it reduces the
> expected CT size (trades off the cost of extra computation
> for effective throughput), and it reduces redundancy, which
> makes methods of C/A that rely on statistics less effective.
> D.Scott is concerned primarily with security, not throughput,
> and his concern about standard compression methods, as I
> understand it, is that they often concentrate some of the
> redundancy at the start of the CT instead of spreading it
> evenly throughout the entire CT. That is worth worrying
> about if security is your prime concern, although my own
> opinion is that it is not a big enough flaw to be exploited
> by practical C/A for most likely systems.
>From my memory of past discussions with Mr. Scott, his
issue is what he terms the 1-1 compression which has to
do with the question whether all decryptions (using all
potentially possible keys) of a ciphertext could be
decompressed (by a given fixed algorithm) without leading to
processing difficulties that would reveal the fact that
wrong decryption keys are being used. I am yet not aware
that his compression scheme does any 'even spreading of
redundancy' throughout the entire CT as compared to the
normal compression algorithms. What he does is some special
manipulations at the end of the file to prevent the
above mentioned detection of wrong keys, if I don't err.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Thomas Shaddack)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => TV detection (was: FBI easily cracks encryption ...?)
Date: 11 Mar 2001 21:33:34 GMT
[EMAIL PROTECTED] (Richard Herring) wrote in
<985r2u$aqp$[EMAIL PROTECTED]>:
>In article <Wknp6.291$[EMAIL PROTECTED]>, John
>Niven ([EMAIL PROTECTED]) wrote:
>> > > what their citizens are watching on TV or listening to
>> > > on radios. (Does England still do that?).
>> > Can you post details about this? I've always thought it was an
>> > urban myth except under lab conditions.
By far not urban myth. I would be very! interested in schematics of a
device that would be able to receive signal from a computer monitor (TVs
should be relatively easier).
I recall in late '80s being a member of electronics hobby group. We were
messing around with a TV, and other part of the group at the next table
were playing with a microcomputer, a PMD-81 connected to another TV. We
were able to receive a bit grainy but clearly readable image from their TV
from distance of about 3-4 meters.
>> Britain's TV Licensing Department used to claim that they had handheld
>> detectors capable of not only detecting that you were watching TV, but
>> also which channel. I don't know anyone who's been caught by such a
>> device, though I do know people who have been caught for other
>> reasons. The current advertising drive suggests that all they know,
>> and need to know, is who doesn't own a TV license.
>
>See http://www.tvlicensing.co.uk
West Germany was using this approach to catch unlicensed TVs as well.
(Maybe still does?)
This borders with TEMPEST problematics, so I will try to talk about it a
bit.
The TV transmits in basically three modes.
The first signal, weak and emitted mainly through the antenna, is the
internal oscillator one. Its frequency directly indicates the channel that
is set up. The tuner itself doesn't transmit much as it is shielded, but
the signal from it leaks to the antenna. The maximum signal strength that
is allowed to leak out can be found on ie. FCC specs.
The second signal, much stronger, is emitted on frequency 15.625 kHz and
originates from the horizontal deflection coils. It is relatively very
strong. It doesn't indicate directly the channel the TV is tuned on, but it
can be found by comparing its phase with the horizontal sync impulses in
the TV signals, as the channels are independent on each other - the
individual stations aren't synchronized. Is leaked mainly through the power
plug.
The third signal comes from the modulated electron beams themselves. It has
no such 'cleanliness' as the signals above show, but unlike them carries
the information about what exactly is on the screen (and could be used to
either get the hsync/vsync extracted from it, or together with the second
signal). (This signal can be - with corrections to luminofor time constant
- acquired even by optical monitoring of the room; reflections of the TV
screen from the walls should be enough.)
The defense against emitting the first signal could be either to separate
the antenna from the tuner by using an antenna amplifier with notch
filters, or a noise generator in the band of the tuner's oscillator, with
power exceeding in orders of magnitude the power of the oscillator itself
(one watt should be by far enough). (Or, the best, both.)
The defense against emitting the second signal could be either good filter
on the power line, or a 15.625 kHz generator with a wobbler, coupled via
capacitors to the mains.
The defense against being compromised by the third signal is mainly in
combination of good shielding of data cables and mainly the CRT tube (as it
is de facto a linear electron accelerator and generates a lot of EM noise),
and noise generating. (And in case of computers, of using TEMPEST
countermeasures like using TEMPEST fonts, etc.)
The intelligence value in the first two signals is currently mainly for TV
receivers detection (or tuned channel detection) - I hadn't heard even
speculations about using the third signal class for this. The third signal,
however, presents direct threat - it can compromise what you watch on your
TV (even when it is from a videotape, and then potentially open you for
blackmailing - remember that affair with (I think) some UK politician whose
records from video rental shop were released to newspapers), or what you
have on your monitor.
According to a friend (RF electronics designer), the circuits to filter/jam
the first two signals could be built for under $30. I will try to get more
details. Don't know what value they could have as a 'real' TEMPEST
countermeasure, though.
PS: Sorry for my English - I am from East Europe and doing my best.
Shaddack, the Mad Scientist
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
