Cryptography-Digest Digest #846, Volume #13 Fri, 9 Mar 01 15:13:00 EST
Contents:
Re: Super strong crypto ("Douglas A. Gwyn")
Re: One-time Pad really unbreakable? (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: One-time Pad really unbreakable? (Mok-Kong Shen)
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: New unbreakable code from Rabin? ("Douglas A. Gwyn")
Re: qrpff-New DVD decryption code ("Douglas A. Gwyn")
Re: Super-strong crypto......................(As if). ("Douglas A. Gwyn")
Re: DES in software and hardware ("Douglas A. Gwyn")
Re: NTRU - any opinions ("Jakob Jonsson")
Re: Sad news, Dr. Claude Shannon died over the weekend. (Derek Bell)
Re: New unbreakable code from Rabin? (Mok-Kong Shen)
8th ACM Conference on Computer and Communications Security CFP
([EMAIL PROTECTED])
Re: Really simple stream cipher (David Wagner)
Re: Super strong crypto (David Wagner)
Re: Tempest Systems (Steve Portly)
Re: => FBI easily cracks encryption ...? (Jim D)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 9 Mar 2001 16:20:52 GMT
David Wagner wrote:
> In any case, there is no need to engage in informal analysis.
> I've already described a mode of operation that seems to fulfill all
> your goals. I can make precise exactly what properties are required
> of the block cipher, and I can rigorously prove that (if you have such
> a block cipher) the resulting mode is secure against _all_ efficient
> chosen-plaintext/ciphertext attacks. Best of all, it is simple and fairly
> efficient. Is there some reason it is unsuitable for your purposes?
As I understood you, the requirements on the block cipher are
not verifiable for any actual example, e.g. AES. That is a
general problem with all-or-nothing (English usage of that
phrase) security proofs; if the conditions aren't fully met
then the degree of security is not known at all.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Fri, 09 Mar 2001 18:20:02 +0100
Ben Cantrick wrote:
>
> Tim Tyler <[EMAIL PROTECTED]> wrote:
> >Nope. The proof of perfect secrecy rests on the availability of a shared
> >unguessable stream. No such thing has ever been demonstrated to exist.
> >
> >Consequently the proof of secrecy of the OTP cannot be transferred onto
> >real-world systems used for actual communication without qualifications
> >being made.
>
> Don't bother me with practical details. Sheesh. ;]
>
> Point is, given the preconditions, an OTP is provably unbreakable.
> Are those conditions very hard, perhaps impossible to meet? Possibly.
> But if you have that random stream, you have unbreakable encryption -
> and provably so.
Barely anybody questions the theoretical value of the
(true) OTP. It's all very well, as long as one is not misled
by one's imaginations to believe that one happens to have
such stuffs in one's own (physical) hand.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 09 Mar 2001 18:31:25 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > If you are considering that kind of security requirement,
> > then you should also be aware of the fact that the
> > block cipher itself, on which your proposal is based,
> > is inherently insecure, I suppose. In that sense, I
> > don't yet see that you have solved the security problem.
>
> I see you have missed the point of my proposal. There
> is a world of difference between ideal security and
> practical security. I am concerned with taking some
> standard symmetric encryption algorithm, which is not
> proven to be secure against all possible cryptanalysis,
> and enhancing the way it is used to provide more security,
> to the point that I can have *confidence* that not even
> the best feasible cryptanalysis is going to be able to
> break it (more likely than some acceptable threshold).
> That might not solve your security problem but it sure
> would solve mine!
Could you please clearly point out the superiority of
you scheme over the following:
(1) Send n blocks E(Pi,K1), then E(K2,KM), and so on,
where KM is a key dedicated for transmitting keys,
while K1, K2, ... are keys each for encrypting
n blocks. (The value of n can be adjusted to
match your bandwidth.)
(2) Compute Ki=E(r,KM), send blocks E(Pi,Ki), where
r is from a PRNG. (Here there is no extention of
bandwidth at all.)
Please also repeat in this connection a formulation of
your scheme comparable to the above so that one can
easily see the differences. Thanks in advance.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Fri, 09 Mar 2001 18:40:01 +0100
"Douglas A. Gwyn" wrote:
>
> Tim Tyler wrote:
> > I believe you are mistaken here. As I understand it, the theory is
> > consistent with sub-atomic physics being random - but it is also
> > completely consistent with it being based on deterministic rules.
>
> Determinism can still involve random processes. The key point
> to realize is that the source of *quantum* randomness has
> properties that are demonstrably different from conventional
> sources of randomness; it cannot be attributed to lack of
> sufficiently detailed knowledge of the state of the generator.
> One clue to this (not fully appreciated by Schroedinger at the
> time he first published his wave equation, so don't feel you've
> missed something obvious) is that whatever is ultimately behind
> the randomness has dimensionality 2, not 1. (I.e., Phase matters.)
Could you please elaborate your first sentence? Do you
mean that the 'fluctuations' that characterise random
processes are averaged out through certain arbitrary
or reasonable rules/conventions or are simply not discernable
at the level of observations or what? Otherwise, anything
that involves 'random' processes can 'by definition' not
be 'deterministic', I suppose.
M. K. Shen
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 09 Mar 2001 17:46:59 GMT
[EMAIL PROTECTED] (Mark Currie) writes:
> OK, read your aadsover.htm and aadswp.htm. Sounds pretty good to me.
>
> Questions:
>
> 1. Would an account holder have to have a separate PK set for each institution
> ?
>
> 2. Does the model allow the account holder to generate the PK set ?
>
> One (possibly minor) problem that I can see is if your private key is
> compromised/lost, in AADS you have to contact all institutions yourself, in
> CADS you only have to contact the CA.
>
> Mark
most of these are business &/or personal preference issues.
Currently if a person has 15 pieces of plastics in their waller, and
their wallet is lost or stolen they have 15 places to notify. However,
there are several 1-800 offerings that can be used to notify all 15.
If a person/business chose to have one or two hardware tokens
registered in multiple places or 15 hardware tokens registered in
multiple places ... there are still 15 places to notify.
The decision of what granularity of 1-to-1 or 1-to-many is
business/personal decision (i.e. business may or may not allow various
options, individuals may or may not to choose various options).
There is some serious issue whether CADS model scales up to large
number of end-points ... either CRLs or OCSP.
The other issue is that significant numbers of businesses, commerical
and financial entities are having difficulty with standard 3rd party
identify certificate model because of privacy and liability reasons.
For instance, the claim that EU is dictating that electronic
transactions at retail point-of-sale will be as anonymous as cash; aka
current payment cards have to remove name & other identification from
plastic and magstripe ... as well as eliminate signature requirement.
The solution has been relying-party-only certificates. The
relying-party-only aspects eliminates serious liability issues. A
relying-party-only certificate carrying just an account number
eliminates the serious privacy issues.
However, walking thru the process flows for relying-party-only
certificate it is possible to show that appending a relying-party-only
certificate (in the CADS-model) is redundant and superfulous.
The other approach it is possible to show that a relying-party-only
certificate appended to every transaction can be compressed to zero
bytes (i.e. every transaction has a CADS zero-byte certificate
appended to every transactions).
misc. refs discussing redundant & superfulous appending of
relying-party-only certificates and/or how relying-party-only
certificates can be trivially compressed to zero bytes.
http://www.garlic.com/~lynn/99.html#238
http://www.garlic.com/~lynn/99.html#240
http://www.garlic.com/~lynn/2000.html#36
http://www.garlic.com/~lynn/2000b.html#53
http://www.garlic.com/~lynn/2000b.html#92
http://www.garlic.com/~lynn/2000e.html#40
http://www.garlic.com/~lynn/2000e.html#47
http://www.garlic.com/~lynn/2000f.html#15
http://www.garlic.com/~lynn/2000f.html#24
http://www.garlic.com/~lynn/2001.html#67
http://www.garlic.com/~lynn/2001c.html#56
http://www.garlic.com/~lynn/2001c.html#8
http://www.garlic.com/~lynn/2001c.html#9
http://www.garlic.com/~lynn/aadsm2.htm#account
http://www.garlic.com/~lynn/aadsm2.htm#inetpki
http://www.garlic.com/~lynn/aadsm2.htm#integrity
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb
http://www.garlic.com/~lynn/aadsm2.htm#scale
http://www.garlic.com/~lynn/aadsm2.htm#stall
http://www.garlic.com/~lynn/aadsm3.htm#cstech6
http://www.garlic.com/~lynn/aadsm3.htm#kiss1
http://www.garlic.com/~lynn/aadsm3.htm#kiss2
http://www.garlic.com/~lynn/aadsm3.htm#kiss4
http://www.garlic.com/~lynn/aadsm3.htm#kiss5
http://www.garlic.com/~lynn/aadsm3.htm#kiss6
http://www.garlic.com/~lynn/aadsmail.htm#variations
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1
http://www.garlic.com/~lynn/aepay4.htm#comcert10
http://www.garlic.com/~lynn/aepay4.htm#comcert11
http://www.garlic.com/~lynn/aepay4.htm#comcert12
http://www.garlic.com/~lynn/aepay4.htm#comcert15
http://www.garlic.com/~lynn/aepay4.htm#comcert2
http://www.garlic.com/~lynn/aepay4.htm#comcert3
http://www.garlic.com/~lynn/aepay4.htm#comcert9
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2
http://www.garlic.com/~lynn/aepay4.htm#x9flb12
http://www.garlic.com/~lynn/ansiepay.htm#simple
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New unbreakable code from Rabin?
Date: Fri, 9 Mar 2001 16:38:37 GMT
Tim Tyler wrote:
> I seem to be justified in describing this claim as "apparently
> ridiculous". It doesn't matter /what/ the details of the system
> proposed are, there's no way such a description can be justified.
> Provably unbreakable codes are simply not known to exist.
Perhaps you should read the paper before you criticize the work.
Under certain reasonable assumptions, a scheme such as Rabin's
does provide "unbreakability", suitably defined. (Whether it is
practical is a separate matter.) The proof is as valid as the
proof of perfect secrecy for OTP, which I saw in another thread
you also take issue with. I've pointed out before that such
skepticism (in the formal philosophical sense) logically entails
rejecting all knowledge about anything, and therefore is not
*practical*. It is *very* important in practice to know such
properties of various systems, as a guide toward implementing
better security. Even though real-world systems are epsilon
away from 100% perfect, if epslion is small enough the system
will be good enough to rely upon to meet our actual goals.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: qrpff-New DVD decryption code
Date: Fri, 9 Mar 2001 16:42:17 GMT
> ]Thus, it does provide _partial_ assistance in controlling the
> ]intellectual property on the DVD.
Bill Unruh wrote:
> very partial.
The really dumb thing about such media copy-protection schemes
(including Macromedia for VHS tapes) is that they often cause
problems for legitimate purchasers, but wholesale piracy
operations are hardly deterred at all, since they can afford
to hack into a playback system to tap off the signal at the
highest available quality point and write that onto the dupes.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super-strong crypto......................(As if).
Date: Fri, 9 Mar 2001 16:47:46 GMT
Benjamin Goldberg wrote:
> The word random really is needed with true one time pad, ...
Strictly speaking, all a one-time pad system really requires
is that the key not be reused, not that the key be patternless.
Of course, if there are regularities in the key stream then the
system does not have the ideal property of perfect secrecy.
> ... Also, like most stream ciphers, it has no built
> in authentification, and it is vulnerable to bit flipping attacks.
? How could you mount a bit-flipping attack against a OTP system?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES in software and hardware
Date: Fri, 9 Mar 2001 17:02:24 GMT
Lovecraftesque wrote:
> I understand that hardware DES implementations are three orders of
> magnitude faster than software ones (roughly speaking.)
That is a meaningless comparison, since there is no basis for
comparability of such radically different implementations, not
even holding clock rates fixed and using the same technology
for the computer that supports the software. Hardware
implementations can have arbitrarily high throughput through
parallelism and pipelining, and if you respond that so can the
computer, then consider that the computer could have a DESenc
instruction to access a built-in hardware DES unit for the
ultimate in speed, making its software performance essentially
the same as the hardware.
> Also, what is usually the performance difference between C
> implementations and hand-coded assembly language ones? I am
> aware that there are many factors involved, like the type of
> platform and how good each implementation is ...
Really good C compilers these days are able to make nearly
optimal use of the computer's instruction set, and on RISC
architectures the bookkeeping required to construct similar
assembly language is rarely worth the effort. The main
exception is when there is some ISA feature that provides a
significant advantage, but that cannot be exploited by the
compiler due to requiring too sophisticated of an analysis
of the algorithm. Use of "carry" bit for multiple-precision
algorithms provides an example, as has been discussed before
(either here or in one of the C newsgroups, I forget which).
In the case of DEA, the S-box functions should be as efficient
in C as in assembly language, and the only real trick would be
blocking operations up to full word size for maximal parallelism.
I think the fastest available C implementations of DEA do just
that, so there is little reason to resort to assembly language.
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Fri, 9 Mar 2001 18:47:42 +0100
Don Johnson was referring to the NTRU signature scheme, not the encryption
scheme. I have much more confidence in the encryption scheme than I have in
the signature scheme. Even though they are based on the same algebraic
structures, they are quite different in nature. Also, remember that the
encryption scheme had some teething troubles in the beginning; this might be
true for the signature scheme as well.
Jakob
"Dan Bailey" <[EMAIL PROTECTED]> wrote in message
news:Pine.SOL.4.10.10103091030390.17575-100000@hickey...
> Anyone (even those who work for Certicom!) who would like a document on
> the extensive scrutiny NTRU has received in the literature can feel free
> to email me. I'll be happy to oblige.
>
> Here's the executive summary: "Better attacks or better lattice reduction
> algorithms are required in order to break NTRU" (Nguyen and Stern, in
> ANTS-2000).
>
> Cheers
> Dan
>
> PS Yes, I work for NTRU.
>
> On 9 Mar 2001, DJohn37050 wrote:
>
> > So, ECC has a space advantage and perhaps NTRU has a speed advantage on
a
> > Pentium, if you believe NTRU is strong. I notice that the NTRU sig
method
> > presented at Crypto is no where to be found (anymore) on the NTRU
webstie,
> > instead a new one from fall 2000 is being offered. What happened to the
old
> > one, did someone break it? Do you think this inspires confidence?
> > Don Johnson
> >
> >
>
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Sad news, Dr. Claude Shannon died over the weekend.
Date: 9 Mar 2001 18:02:21 -0000
John M. Gamble <[EMAIL PROTECTED]> wrote:
: According to the NYT obit, he suffered from Alzheimer's. So he wasn't
: much in the public eye for the last years of his life.
Alzheimers is truly a terrible thing to suffer from;
it's one of the most terrifying things I know of - the slow erasure of
ones' personality. Still, there is some progress in seeking a cure.
: It's a shame. From the description in the obit, he was a lively fellow.
: One wonders if anyone else ever pogo-sticked down the Bell Labs hallways?
Now *there's* something else I didn't know about him! Was he
anything like Feynman? Sounds like quite a character!
Derek
--
Derek Bell [EMAIL PROTECTED] |"Usenet is a strange place."
WWW: http://www.maths.tcd.ie/~dbell/index.html| - Dennis M Ritchie,
PGP: http://www.maths.tcd.ie/~dbell/key.asc | 29 July 1999.
|
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New unbreakable code from Rabin?
Date: Fri, 09 Mar 2001 19:45:37 +0100
"Douglas A. Gwyn wrote:
>
> Under certain reasonable assumptions, a scheme such as Rabin's
> does provide "unbreakability", suitably defined. (Whether it is
> practical is a separate matter.) The proof is as valid as the
> proof of perfect secrecy for OTP, which I saw in another thread
> you also take issue with. I've pointed out before that such
> skepticism (in the formal philosophical sense) logically entails
> rejecting all knowledge about anything, and therefore is not
> *practical*. It is *very* important in practice to know such
> properties of various systems, as a guide toward implementing
> better security. Even though real-world systems are epsilon
> away from 100% perfect, if epslion is small enough the system
> will be good enough to rely upon to meet our actual goals.
I agree with your second to last sentence but have a little
bit difficulty with your last sentence. In the case of
OTP, there seems to be no rigorous method to define and
measure that epsilon, not to say what max. epsilon one
should use in a concrete situation. Thus, after applying a
certain number of statistical tests, one is more or less
left to employ one's subjectivity (or in other words,
guesses) to decide whether a bit sequence is good enough
to be used in the way a theoretical OTP is used.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security
Subject: 8th ACM Conference on Computer and Communications Security CFP
Date: Fri, 09 Mar 2001 19:18:23 -0000
Reply-To: [EMAIL PROTECTED] (replayer-return)
Also available at: http://www.bell-labs.com/user/reiter/ccs8/cfp.html
Call For Papers
Eighth ACM Conference on Computer and Communications Security
Doubletree Hotel, Philadelphia, Pennsylvania, USA
November 6-8, 2001
Sponsored by ACM SIGSAC
Papers offering novel research contributions in any aspect of computer securityare
solicited for
submission to the Eighth ACM Conference on Computer and Communications Security.
Papers may present
theory, technique, applications, or practical experience on topics including:
access control data/system integrity
security for mobile code intrusion detection
cryptographic protocols security management
key management security verification
information warfare database and information system
authentication security
applied cryptography smart-cards and secure PDAs
e-business/e-commerce inference and controlled disclosure
privacy and anonymity intellectual property protection
secure networking commercial and industry security
accounting and audit
The primary focus is on high-quality original unpublished research, case studies, and
implementation
experiences. We encourage submissions discussing the application and deploymentof
security
technologies in practice.
Paper submissions Submitted papers must not substantially overlap papers thathave
been published or
that are simultaneously submitted to a journal or a conference with proceedings.
Papers should be at
most 15 pages excluding the bibliography and well-marked appendices (using 11-point
font and reasonable
margins on letter-size paper), and at most 20 pages total. Committee members are not
required to read
the appendices, and so the paper should be intelligible without them. All submissions
should be
appropriately anonymized (i.e., papers should not contain author names or
affiliations, or obvious citations).
To submit a paper, send to [EMAIL PROTECTED] a plain ASCII text email containing the
title and abstract
of your paper, the authors' names, email and postal addresses, phone and fax numbers,
and identification
of the contact author. If any bibliographic citations were blinded from the paper for
anonymous review,
then include the full bibliographic citations in this email message. To the same
message, attach your
submission (as a MIME attachment) in PDF or portable postscript format. Do NOT send
files formatted for
word processing packages (e.g., Microsoft Word or WordPerfect files). Papers must be
received by the
deadline of April 30, 2001. Accepted papers will be presented at the conferenceand
published by the ACM
in a conference proceedings. Outstanding papers will be invited for possible
publication in a special
issue of the ACM Transactions on Information and System Security.
Panel proposals Proposals should be no longer than 5 pages in length, should include
possible panelists
and an indication of which panelists have confirmed participation. Send to
[EMAIL PROTECTED] a plain
ASCII text email containing the title of your panel and contact information. Tothe
same message, attach
your proposal (as a MIME attachment) in ASCII, PDF, or portable postscript format. Do
NOT send files
formatted for word processing packages (e.g., Microsoft Word or WordPerfect files).
Panel proposals must
be received by the deadline of April 30, 2001.
General Chair
Mike Reiter (Bell Labs, USA)
email: [EMAIL PROTECTED]
Tutorial Chair
Matt Franklin (UC Davis, USA)
Publication Chair
Ed Felten (Princeton Un., USA)
Publicity Chair
Ari Juels (RSA Laboratories, USA)
Program Chair
Pierangela Samarati
DSI - UniversitM-` di Milano
Via Bramante, 65
26013 - Crema - ITALY
email: [EMAIL PROTECTED]
phone: +39-0373-898237
fax: +39-0373-898253
Steering Committee Chair
Ravi Sandhu (GMU, USA)
Important dates
Paper submission due: April 30, 2001
Panel submission due: April 30, 2001
Acceptance notification: June 30, 2001
Final papers due: July 30, 2001
Program Committee
Viajy Atluri, Rutgers University, USA
Frederic Cuppens, Onera Toulose, FR
S. De Capitani di Vimercati, Un. Brescia, IT
Yvo Desmedt, Florida State Univ., USA
Ed Felten, Princeton University, USA
Ulrich Flegel, Un. Dortmund, Germany
Ravi Ganesan, Checkfree, USA
Virgil Gligor, University of Maryland,USA
Anup Ghosh, Cigital, USA
Dimitrisb Gritzalis, AUEB, Greece
Joshua Guttman, Mitre, USA
Steve Kent, BBN, USA
Michiharu Kudo, IBM TRL,Japan
Trent Jaeger, IBM Watson,USA
Pat Lincoln, SRI International,USA
Peng Liu, Univ. of Maryland BC,USA
Teresa Lunt, Xerox PARK,USA
John McLean, Naval Res. Lab., USA
Hilarie Orman, Novell, USA
B. Preneel, Kath. Univ. Leuven,Belgium
Mike Reiter, Bell Labs, USA
Ravi Sandhu, George Mason Univ.,USA
Michael Steiner, Un. Saarlandes, Germany
Paul Syverson, Naval Res. Lab., USA
Giovanni Vigna, UCSB, USA
Moti Yung, CertCo, USA
Rebecca Wright, AT&T Labs, USA
--
Sent by ajuels from yahoo subpart from com
This is a spam protected message. Please answer with reference header.
Posted via http://www.usenet-replayer.com/cgi/content/new
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 9 Mar 2001 19:21:07 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Henrick Hellstr�m wrote:
>Every application that utilizes any kind of security primitive has to be
>designed in a particular way in order not to weaken that security primitive.
I prefer to minimize the number of ways that a cipher can be misused.
Since there are alternatives (e.g., MACs) that do not require the
application to reject gibberish, I see no good reason to introduce
unnecessary failure modes.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 9 Mar 2001 19:24:23 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>As I understood you, the requirements on the block cipher are
>not verifiable for any actual example, e.g. AES.
Yes, this is the limitation of the technique. But: What reason do we have
to believe that the "super-strong" mode is any better in this regard?
I can't even tell what the requirements for the "super-strong" mode
are, let alone verify whether any cipher (e.g., AES) satisfies them.
Please correct me if I'm wrong in this regard.
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Fri, 09 Mar 2001 14:33:04 -0500
Mok-Kong Shen wrote:
> Lyalc wrote:
> >
> > The ideal environment, it seems:
> > - small physical perimeter (the cell)
> > - meaning close, easily adjustbale antenna/sensor placement
> > - possiblility to screen from outside electrocal noise (is the cell inside a
> > screened environment - the stealth bomber was tested inside a fully screened
> > hangar)
> > - total accessability to all power and comms lines
>
> Couldn't one create noise with some appropriate generators
> to defeat monitoring?
>
> M. K. Shen
You would think that an adversary could distinguish the location of a noise
generator from the true location to be monitored given sufficient time
discrimination.
------------------------------
From: [EMAIL PROTECTED] (Jim D)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 19:51:06 GMT
Reply-To: Jim D
On Fri, 09 Mar 2001 10:44:38 GMT, "Mxsmanic" <[EMAIL PROTECTED]> wrote:
>"Damian Kneale" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>
>> Once you have that, you do the key cracking or
>> recovery. Its hard, but not impossible. If it
>> weren't possible, virtually every western
>> government wouldn't have sigint agencies.
>
>There is far more to signal intelligence than just cracking codes. If
>cracking codes were all it included, then indeed no spook agencies would
>still have it, since cracking codes isn't a very success-prone endeavor
>these days.
Right. COMINT does more traffic analysis and commercial/
industrial espionage that it does codebreaking.
Just knowing that A communicated with B and C at a particular
time, just before B and C moved their troops westwards.
They don't necessarily need to know the content of the
encrypted communication. It's handy enough to know when
it was sent; by whom and to whom.
--
___________________________________
George Dubya Bushisms No 4:
'Welcome to Mrs Bush and my
fellow astronauts.'
Posted by Jim Dunnett
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________
------------------------------
** 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
******************************
