Cryptography-Digest Digest #843, Volume #13 Fri, 9 Mar 01 06:13:01 EST
Contents:
Re: Q: Tempest Systems (Frank Gerlach)
Re: PKI and Non-repudiation practicalities (Mark Currie)
Re: PKI and Non-repudiation practicalities ("Lyalc")
Re: Tempest Systems ("Lyalc")
Re: Tempest Systems (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: => FBI easily cracks encryption ...? (Damian Kneale)
Re: DES in software and hardware ("Thierry Falissard")
Re: frequency "flattening" (Joe H. Acker)
Privat keys in Microsoft (Swood)
Re: => FBI easily cracks encryption ...? (Chris)
Re: => FBI easily cracks encryption ...? (Chris)
Re: One-time Pad really unbreakable? (Tim Tyler)
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: One-time Pad really unbreakable? (Tim Tyler)
Re: OT: The Big Breach (book) available for download ("Dan G")
----------------------------------------------------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Q: Tempest Systems
Date: Fri, 09 Mar 2001 08:30:43 +0100
"Douglas A. Gwyn" wrote:
> It should be pointed out that in that application the
> signal was engineered specifically for forward error
> correction, unlike the vast majority of the signals
> in common computers.
Transmitting the same signal multiple times can also be considered FEC.
CRTs transmit the same signal 50 to 100 times a second, often for
minutes or even hours..
This is a lot of fun for the seasoned sigint engineer with government
resources at disposal :-)
Laptops might be a little better in that respect, but this depends
highly on the screen technology.
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
From: [EMAIL PROTECTED] (Mark Currie)
Date: 09 Mar 2001 07:36:56 GMT
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
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[EMAIL PROTECTED] (Mark Currie) writes:
>
>> Hi,
>>
>> Ok, I see now where you changed to discussing this model (AADS). I am not
>> familiar with this model, I guess that I will have to visit your site. It
>> sounds interesting.
>>
>> Mark
>
>as per prior note ... after working on
>
>http://www.garlic.com/~lynn/aadsm5.htm#2
>http://www.garlic.com/~lynn/aadsm5.htm#3
>http://www.garlic.com/~lynn/aadsm5.htm#4
>http://www.garlic.com/~lynn/aadsm5.htm#1
>
>it seemed to be worthwhile to look at a public key infrastructure
>model that preserved the existing trust and business process models.
>
>random refs:
>http://www.garlic.com/~lynn/aadsover.htm
>http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
>http://www.garlic.com/~lynn/aadswp.htm
>
>CAs and certificates were an design point to address trust in offline
>email where little or no trust processes existed ... which might show
>a net benefit. However, introducing a new trust participant in
>existing value transactions containing significant number of stake &
>trust members is a very, very difficult business process. If the
>argument is purely based on better authentication technology .... then
>do an implementation that is a technology public key infrastructure
>w/o having to introduce new trust partners into every transaction.
>
>For a technology demonstration, a CA-base with certificates is a
>possibly less expensive demo scenerio i.e. a couple thousand
>certificates and some boundary demonstration of signed transaction
>which then are converted into standard business form and processed in
>the normal way. Somebody takes a risk acceptance on the fact that the
>limited demo isn't integrated into the standard trust and business
>processes. The trade-off is the integration of the public key
>infrastructure into the existing business & trust processes (1-5% of
>the existing data processing infrastructure costs) versis scaling a
>CA-base with certificates into a duplicate of the existing business &
>trust processes (100% of the existing data processing infrastructure
>costs) plus syncronizing the CA-base and the existing base for things
>like referential integrity (possibly another 100% of the base).
>
>The cut-over from the CADS-model for demo purposes to integrated
>AADS-model would be at 1-5% of the account base plus any risk exposure
>because of a non-integrated operation.
>
>Part of some of the AADS-model scenerios has been trying to
>demonstrate overall cost savings converting to public key
>infrastructure authentication from existing business authentication
>methods (i.e. various benefits are larger than the cut-over costs).
>Part of that is looking for existing transition activities and attempt
>to merge a AADS-model transition into some transition that is already
>going to be done and has been cost justified for other reasons.
>
>--
>Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Fri, 9 Mar 2001 18:57:59 +1100
Mark Currie wrote in message <3aa88818$0$[EMAIL PROTECTED]>...
>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
>?
Not necessarily. In the same way you may choose that have the same password
with different systems, or the same PIN with different payment cards, the
individual authentication relationship does not, and usually cannot compare
with any other authentication relationship you may have formed.
>
>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.
In the PKI models, every digsig recipient has to check every cert for
revocation. Which is simple and more efficient? AADS models wins, in my
book.
Lyal
>Mark
>
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>>
>>[EMAIL PROTECTED] (Mark Currie) writes:
>>
>>> Hi,
>>>
>>> Ok, I see now where you changed to discussing this model (AADS). I am
not
>>> familiar with this model, I guess that I will have to visit your site.
It
>>> sounds interesting.
>>>
>>> Mark
>>
>>as per prior note ... after working on
>>
>>http://www.garlic.com/~lynn/aadsm5.htm#2
>>http://www.garlic.com/~lynn/aadsm5.htm#3
>>http://www.garlic.com/~lynn/aadsm5.htm#4
>>http://www.garlic.com/~lynn/aadsm5.htm#1
>>
>>it seemed to be worthwhile to look at a public key infrastructure
>>model that preserved the existing trust and business process models.
>>
>>random refs:
>>http://www.garlic.com/~lynn/aadsover.htm
>>http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
>>http://www.garlic.com/~lynn/aadswp.htm
>>
>>CAs and certificates were an design point to address trust in offline
>>email where little or no trust processes existed ... which might show
>>a net benefit. However, introducing a new trust participant in
>>existing value transactions containing significant number of stake &
>>trust members is a very, very difficult business process. If the
>>argument is purely based on better authentication technology .... then
>>do an implementation that is a technology public key infrastructure
>>w/o having to introduce new trust partners into every transaction.
>>
>>For a technology demonstration, a CA-base with certificates is a
>>possibly less expensive demo scenerio i.e. a couple thousand
>>certificates and some boundary demonstration of signed transaction
>>which then are converted into standard business form and processed in
>>the normal way. Somebody takes a risk acceptance on the fact that the
>>limited demo isn't integrated into the standard trust and business
>>processes. The trade-off is the integration of the public key
>>infrastructure into the existing business & trust processes (1-5% of
>>the existing data processing infrastructure costs) versis scaling a
>>CA-base with certificates into a duplicate of the existing business &
>>trust processes (100% of the existing data processing infrastructure
>>costs) plus syncronizing the CA-base and the existing base for things
>>like referential integrity (possibly another 100% of the base).
>>
>>The cut-over from the CADS-model for demo purposes to integrated
>>AADS-model would be at 1-5% of the account base plus any risk exposure
>>because of a non-integrated operation.
>>
>>Part of some of the AADS-model scenerios has been trying to
>>demonstrate overall cost savings converting to public key
>>infrastructure authentication from existing business authentication
>>methods (i.e. various benefits are larger than the cut-over costs).
>>Part of that is looking for existing transition activities and attempt
>>to merge a AADS-model transition into some transition that is already
>>going to be done and has been cost justified for other reasons.
>>
>>--
>>Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
>
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Fri, 9 Mar 2001 19:02:20 +1100
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
lyal
news.singnet.com.sg wrote in message <987v0r$jdg$[EMAIL PROTECTED]>...
>I've just finished reading the cryptoanalysis thriller Cryptomonicon (hope
I
>spelled it right) by Neal Stephenson and was intrigued with the last few
>chapters where the main character has to sit in his captors' jail cell with
>his laptop he is allowed to use.
>
>The captors of course have set up a tempest system to capture signals and
>visuals from his notebook computer and the methods he uses to throw them
off
>track are quite clever.
>
>Any comments on this? Would never happen? Tempest systems aren't that good?
>Etc.
>
>Thanks in advance.
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Fri, 09 Mar 2001 10:02:05 +0100
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
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 09 Mar 2001 10:31:11 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Perhaps you should also check in those your cases whether
> > the keys need to be perfectly random (barely realistic)
> > and (in case no) whether using pseudo-random keys
> > (thus permitting no expansion of bandwidth) is feasible.
>
> The enemy must have no information about the actual
> (shared secret) key, which means it must be generated by a
> random process. If instead you generate it using some
> deterministic method, the enemy can use the same method.
>
> If you mean that the initial key is a truly randomly
> generated shared secret but that later "keys" are derived
> from it using a deterministic algorithm, then that key
> scheduling algorithm can be cryptanalyzed. One of the
> changes from Lucifer to DES was to address that issue.
> In effect the key scheduling algorithm becomes part of the
> "general system" and only the initial key is the "key" for
> that system. That reduces the problem to where we started.
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.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Damian Kneale)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 09:47:23 GMT
Once Paul Rubin <[EMAIL PROTECTED]> inscribed in stone:
>[EMAIL PROTECTED] (Damian Kneale) writes:
>> To wade into the whole "capabilities" debate, the choice seems fairly
>> simple. Have a government capable of breaking code and listening at
>> will, or have one that cannot. Being from Australia, a country
>> defended from Japan during WW2 largely due to successes in
>> codebreaking, I'm all for a government that has that capability.
>> Making sure your government is trusted with that capability is a
>> little tougher...
>
>You're a little confused though. That type of codebreaking against
>modern crypto is impossible as far as anyone can tell. Unlike in WW2,
>governments *can't* break today's codes--that's why they want to
>regulate people using them. The government can only listen in on
>people who obey the regulations.
I'm not that confused. Codebreaking comes in several stages, the
first of which is just finding the relevant code. Diplomatic codes
tend not to be standard ones, and just finding it can be fun by all
accounts. 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.
I think you mis-understand who listens to what. Police and internal
law enforcement are authorised to monitor communications under the
relevant legislation, and generally have tight controls. Government
agencies such as the NSA/GCHQ listen to foreign governments, citizens
and companies.
I'd bet you _all_ your lifetime earnings that at least some government
level codes are crackable. Even a 5-10% success rate is a good
success rate in terms of giving a picture of ongoing activities.
>Do you seriously think the enemy (either an enemy in a war, or a
>terrorist, or even an ordinary criminal) is going to obey the
>regulations?
Not at all, and do you think that the NSA are about to admit that they
can listen in to (as a random example) Japanese Diplomatic codes, but
not naval codes? Or that France has better encryption and key
generation than Spain? Legislation to make a job easier is a long way
from proving it cannot be done. The recent report to the European
parliament would tend to imply otherwise, if you believe the findings.
>If not, exactly what is left for the regulation supposed to protect
>you against?
Ask instead what the government wishes to know. I don't recall any of
this sort of legislation being justified as helping the individual,
instead if helps "society" or "the country".
If you truly believe code breaking isn't possible for good codes, why
resist the trend to legislate? Just use PGP and trust your keys (give
false ones if you have to - at least you'll know when you are being
investigated, as someone will have to knock on your door to tell you
that yours keys are "out of date" - that will of course be your
excuse!).
Damian.
------------------------------
From: "Thierry Falissard" <[EMAIL PROTECTED]>
Subject: Re: DES in software and hardware
Date: Fri, 9 Mar 2001 10:50:48 +0100
On IBM mainframes, I found that hardware DES was 4 times
faster than the best software implementation.
http://os390-mvs.hypermart.net
"Lovecraftesque" wrote:
> I understand that hardware DES implementations are three orders of
> magnitude faster than software ones (roughly speaking.) I wonder if
> anybody can provide pointers to more precise data?
>
> 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 but, again, feedback on this would be welcome.
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: frequency "flattening"
Date: Fri, 9 Mar 2001 10:47:37 +0100
Thanks a lot for all of your replies!
I now know how to achieve what I was looking for and were to find
further references. But before I actually implement such a beast (I'm
not that experienced and algorithmic encoding or similar methods aren't
trivial), here's the question you probably have anticipated:
If I do a homophonic substitution at byte level, such that all bytes
0..255 have the same frequency: Would this make cryptanalysis
significantly harder if used as input for a symmetric block cipher such
as Rijndael?
Most agree that compression like zlib can increase security, but equal
frequencies of each input symbol seems to be even more desirable. (Some
classic paper&pen ciphers use homophonic substitution based on letter
frequencies of the plaintext language.) On the other hand, using this
encoding, plaintext might even get larger, so there's more ciphertext as
well.
What do you think?
> "An information-theoretic treatment of homophonic substitution" by H.
> N.Jendal, Y. J. B. Kuhn and J. L. Massey, Advances in Cryptology
> EuroCrypt '89, pp. 382-394.
>
> with cryptanalysis of the variable-length homophonic substitution (as
> originally presented in Gunther's paper) from an information-theory
> viewpoint.
I'll have a look at this.
Regards,
Erich
------------------------------
From: Swood <[EMAIL PROTECTED]>
Subject: Privat keys in Microsoft
Date: Fri, 09 Mar 2001 11:11:22 +0100
Hello all,
Does anyone now where, and how, are the private keys (those which
correspond to IE certs) stored and protected on windows (NT, 2000,
95...)?
Thank's a lot,
Cheers,
Swood.
------------------------------
Date: Fri, 09 Mar 2001 21:10:46 +1100
From: Chris <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
> What I am missing in this discussion is traffic analysis by the NSA.
That's because everybody knows it's hapenning. Both online and by telephone.
ever heard of "NetMap" ? Drug smugglers worst nightmare.
------------------------------
Date: Fri, 09 Mar 2001 21:15:46 +1100
From: Chris <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Mxsmanic wrote:
> "Thomas Boschloo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > What I am missing in this discussion is traffic
> > analysis by the NSA.
>
> I believe I've already mentioned it.
>
> > BTW Crypto even is a better target, if not too many
> > people use it.
>
> In the not-so-distant future, just about everything will be encrypted,
> although which methods of encryption will be used are still open to
> debate.
>
> Most Web transactions are being secured already (by SSL).
Crap. "SSL" is a socket level encryption thing. It "secures" only one
part of the communication - in the socket layer. most web "transactions"
"secured" by SSL are people buying stuff with credit cards - the
"transaction" starts when they push the button (no security) and
continues through their PC operating system (no security) to the
application software (no security) which then calls crypto APIs
(in plaintext) to finally get something "protected" to shuffle around.
This is reversed again at the other end, levaing two giant gaping
security holes for anyone to use as they see fit.
If anyone has the technology to eavesdrop on TCP traffic, they
also have the technology to alter it, which by default gives them the
facility to inject whatever monitoring code they want into your
computer.
goodbye SSL...
That's why the "SET" protocol died. they solved nothing new.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 9 Mar 2001 10:29:27 GMT
Ben Cantrick <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Jim D <[EMAIL PROTECTED]> wrote:
:>: I can send you a piece of OTP cipher and I'll guarantee
:>: you won't break it in a million years.
:>
:>What will that prove? How can I place any trust in your guarantee?
:>I don't know you from Adam.
: The security of a one-time pad does not rest on trusting some random
: person on USENET. Used properly, it is a (perhaps the only) provably
: unbreakable cypher.
: See http://web.ranum.com/pubs/otpfaq/
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.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 10:44:38 GMT
"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.
> I'd bet you _all_ your lifetime earnings that
> at least some government level codes are crackable.
Since it is easy to use a very secure cryptosystem today, I doubt that
any significantly weak ones are in use, at least in domains where
organizations like the NSA have a say in their selection. While these
secure cryptosystems are certainly crackable in a theoretical sense, in
a real-world sense, they probably aren't.
> Even a 5-10% success rate is a good success rate
> in terms of giving a picture of ongoing activities.
I suspect this is over-optimistic by many orders of magnitude.
> If you truly believe code breaking isn't possible for
> good codes, why resist the trend to legislate?
Because if you are thrown into jail for just using a code, it deletes
the utility of the code significantly.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 10:49:42 GMT
"Chris" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Crap. "SSL" is a socket level encryption thing.
> It "secures" only one part of the communication -
> in the socket layer.
That's the part that needs to be secured the most.
> ... the "transaction" starts when they push the
> button (no security) and continues through their
> PC operating system (no security) to the application
> software (no security) which then calls crypto
> APIs (in plaintext) to finally get something
> "protected" to shuffle around.
The data only needs to be encrypted on the wire. The rest doesn't
matter. Petty crooks and kiddies are only going to be intercepting the
contents of data packets, if anything. They are not going to be
monitoring emanations from a keyboard from a black helicopter.
The protection needs to be appropriate for the purpose.
> If anyone has the technology to eavesdrop on TCP
> traffic, they also have the technology to alter
> it ...
Not so. I have my Netmon program that lets me watch traffic in and out
of my PC, but it doesn't let me modify anything at all.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 9 Mar 2001 10:59:32 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: In contrast, the irreducible nature of quantum randomness has been well
: established by experiment and theory. It's not due merely a lack of
: more detailed knowledge of the state of the system.
Yet there are deterministic theories of how the world operates, which
appear to be quite consistent with observation:
http://www.anthropic-principle.com/preprints/manyworlds.html
Q13 Is many-worlds a deterministic theory?
Yes, many-worlds is a deterministic theory [...]
A deterministic theory has no place for randomness.
Anyway, regardless of whether quantum events tap into fundamentally
unpredictable phenomena or not the question of how to get an unguessable
shared stream to both parties while ensuring that nobody else can
predict the information remains.
This problem is to do with macroscale devices, couriers, whether your
component suppliers can be trusted, whether the state of your randomness
detector is being remotely monitored, and so on.
Quantum theory doesn't come into this discussion - it's a bit of a red
herring, really.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Dan G" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: OT: The Big Breach (book) available for download
Date: Fri, 9 Mar 2001 13:13:59 +0200
I've been trying (the word.zip) as well unsucedfully several times (by using
the explorer save as). Finally I've tried with download accelerator and was
a success (btw this site permits via the accelerator to pasue and retry an
unfinalised download). It took me several minutes.
------------------------------
** 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
******************************
