Cryptography-Digest Digest #848, Volume #13 Fri, 9 Mar 01 19:13:00 EST
Contents:
Re: PKI and Non-repudiation practicalities ("Lyalc")
Re: Tempest Systems ("Lyalc")
Re: Tempest Systems ("Lyalc")
Re: Text of Applied Cryptography ("Ryan M. McConahy")
Re: Tempest Systems ("Lyalc")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Applications of crypto techniques to non-crypto uses (Mok-Kong Shen)
Re: PKI and Non-repudiation practicalities (Daniel James)
Re: NTRU - any opinions (David A Molnar)
Re: Super-strong crypto......................(As if). ("Henrick Hellstr�m")
Re: Tempest Systems (Steve Portly)
Re: Encryption software ("Henrick Hellstr�m")
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
----------------------------------------------------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Sat, 10 Mar 2001 09:15:36 +1100
>>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.
>
>more efficient for whom? if i have 8 institutions, say 2 banks and 6
>credit cards, the compromise (loss) of my private secret means that: a) i
>have to request a replacement (i assume that the aads model will create an
>industry for direct to consumer supply); b) be fucked until the new secret
>is delivered (since i cannot access anything without it); and c) contact
>all 8 institutions myself to activate the token/secret once it arrives. i
>can't imagine that this gets any better when you are outside your home
>area/country.
The AADS model can allow the individual to generate their own
keys/certificate - they are specifically registers to an individual
commercial or messaging relationship.
You remain able to re-enable keys/certificates relationships first with the
people most important to you (after telling all to cease use of the
compromised ones) and re-enabling electronc ties with the others later.
This is what you do now with a wallet full of cards, a list of internet
emails, registered web sites etc.
lyal
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Sat, 10 Mar 2001 09:16:51 +1100
Yes
Lyal
Steve Portly wrote in message <[EMAIL PROTECTED]>...
>
>
>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: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Sat, 10 Mar 2001 09:24:23 +1100
Every state transition from a 1 to 0 or vice versa is detectable in some
way, not always usefully so when you have some meters away from the unit.
Screens, keyboards, printer port/cables, serial port/cables, hard disk
drives (getting tricky), floppy drives, the on-off switch (it at least tells
you the machine is on!), printer, modem, ethernet card etc
Different by brand, model and implementation, so for a PC brand X look at
screen and keystrokes info, while for brand Y look at printed data, screen
and the network interface hardware.
This is where the cost/complexity challenge to the attacker really starts to
bite them.
And no, I'm not aware of any 'by component' rating of the Tempest rating of
workstation sub components, though this may exist somewhere. It won't be
easy to build a low emanation machine by careful component selection, but
theoretically possible.
Lyal
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>
>
>Steve Portly wrote:
>>
>> 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.
>
>Dumb question: What are the major activities of a computer
>that could be well monitored through electromagnetic
>emanations? Thanks.
>
>M. K. Shen
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Crossposted-To: alt.anonymous.messages,alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography
Date: Fri, 9 Mar 2001 17:31:37 -0500
I am _not_ a troll! If I can't find it from you, I'll find it somewhere
else.
Tom St Denis wrote in message
<03go6.14332$[EMAIL PROTECTED]>...
>
>"Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
>news:3aa18702$0$30007$[EMAIL PROTECTED]...
>> Anywhere for free on the net?
>
>Look troll boy, Applied Crypto IS NOT FREE.
>
>Tom
>
>
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Sat, 10 Mar 2001 09:33:55 +1100
The theory I remember is essentially:
Noise is essentially random. Any averaging process will average noise to a
medium "DC-like" steady state given enough samples.
The target signal will (if repetitive) not average to 0, but to some level
above that.
Typically, noise 1 +noise 2 = 3dB increase in the summed noise.
signal 1 + signal 2 = 6dB increase in usable, averaged signal, neglecting
the inherent noise of your sensor/detector equipment, especialy that of the
front end amplifier.
Thus an S/N of -6dB would mean at least 3 samples would be needed to bring
it to an 0dB S/N. Remember, the noise average increases as well, whuile we
are interested in the variations about that steady state 'noise average'
level.
But a better explanation is contained in the theory and papers on spread
spectrum trannsmission, used by everyone from ham radio operators through
taxis, GSM, CDMA, space transmissions and chunks of the military.
Lyal
Frank Gerlach wrote in message <[EMAIL PROTECTED]>...
>Frank Gerlach wrote:
>>
>> Mok-Kong Shen wrote:
>>
>> > Couldn't one create noise with some appropriate generators
>> > to defeat monitoring?
>> Very difficult, because the noise is added additively, unlike a stream
>> cipher, which uses a nonlinear function like XOR. This means that you
>> can simple average out the noise, if the signal is sent multiple times
>> (as with a lot of computer signals).
>Maybe some electrical engineers in this group can give an estimation how
>many signal repetitions are necessary for a given Signal-to-noise ratio.
>Is this the Shannon formula ?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Fri, 09 Mar 2001 14:39:04 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Scott Fluhrer wrote:
> > >
> > > It is written "Argue not with a fool, lest you be like him". Here I
> > > go again ignoring that excellent advise...
> > >
> > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Scott Fluhrer wrote:
> > > > >
> > > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > > > <SNIP BIGTIME>
>
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
You've taken your first quote out of context. I has meaning when you
include the two immediately following sentences.
"A file can be written to one place on a hard drive then read into
cache. Processed then written to a completely different place on
the hard drive. And this process can continue I suppose until the
entire hard drive has been written over once and no bit locations
have been overwritten."
File is opened in "r+b" mode.
A block is loaded into cache not a sector. Block sizes vary.
I believe that there are plenty of statistics available that prove
the accuracy, reliability and predictability of computer technology.
And most bad sectors have been previously identified and are
routinely avoided where they will not cause runtime errors in write
/ read operations.
I don't believe that the entire block (not sector) from cache is
rewritten back to the hard drive. This would be inefficient. I am
quite sure that at most only the updated file is rewritten to the
hard drive. But a good point of focus.
Most likely when the overwrite program is the only program running
and the only program accessing the hard drive that the drive heads
will remain where they last read / wrote from / to the hard drive.
As well, there are most likely other blocks on both sides of the
block / file to be rewritten to the hard drive and this location
will be closest and I would think most likely that the rewrite will
most likely take place at the original file location.
The OS and hardware cannot ignore a coded instruction indefinitely.
This is the reasoning behind my updating the OverWrite program. If
the OS and hardware is given enough time it will carry out the write
operation.
Are you arguing otherwise?
Compressed files: This was another point raised. Wouldn't you agree
that the user is intending to overwrite the file as it exists. How
it got to be the file it is is not the concern of the OverWrite
program. This may be a concern of the user.
"I think that by now, everyone [except Szopa] is able to see that his
algorithm is not guaranteed to properly overwrite an arbitrary file."
I guess I struck a cord for you to jump to such a conclusion in light
of my just made point, no? I do not believe that debate is about
winning at all costs. I believe it is about getting to the truth of
an issue. When a person lies or tries to deceive then the debate has
gone off topic but not necessarily void of enlightenment.
Defragmented disks: again, OverWrite is not responsible for multiple
file copies. It is only tasked with overwriting the file you tell it
to.
Transactioning: Same as above. What you might want to do is write a
file large enough to cover your entire hard drive then use OverWrite
to overwrite your entire damned hard drive ;-)
Raid disks: if you have multiple copies of a file that you want to
overwrite then you must tell the OverWrite program to overwrite each
and every one of them.
It sounds like what you are proposing is that I upgrade the OverWrite
program to also scan your entire hard drive byte by byte for any
partial strings that are sub strings of the file you are intending to
overwrite as well and over write these as well. Good idea. I'll
keep it in mind.
But for now, the OverWrite program is a simple overwrite utility.
Tell it to overwrite one file and I believe it does it and I have
told you why.
"If they were in ROM, they would be hard coded." No, they would be
firm coded.
I think this should be enough for you all to chew on for today.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Applications of crypto techniques to non-crypto uses
Date: Fri, 09 Mar 2001 23:51:16 +0100
A US company claims to have developed a software that greatly
reduces the number of key strokes for typing SMS messages on
a cellphone in most cases, alledgedly employing techniques
that are related to crypto for resolving the ambiguities that
arise from the reduction of the amount of keying (with the
help of a database of common words, if I understand correctly).
Some descriptions are to be found in
http://www.eatoni.com/wordwise/wordwise_index.html
Are there other known applications of crypto techniques to
non-crypto uses? Thanks.
M. K. Shen
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Fri, 09 Mar 2001 23:26:35 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler wrote:
> if you had one hardware token in your wallet registered with 15
> different institutions or 15 hardware tokens in your wallet ... the
> lost/stolen risk is still that if your wallet is lost/stolen you have
> to contact 15 different institutions ... or register with a 1-800
> service that contacts all institutions.
There's also an interesting question of how you prove that you really are the
owner/authorized user of the allegedly lost/stolen token when reporting its
loss/theft ... and of how the service operating the 1-800 number proves to your
financial institutions that you really did report the cards missing.
CRLs should always be signed, to frustrate denial of service attacks.
Cheers,
Daniel.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: 9 Mar 2001 23:29:15 GMT
Jakob Jonsson <[EMAIL PROTECTED]> wrote:
> encryption scheme had some teething troubles in the beginning; this might be
> true for the signature scheme as well.
Plus signatures seem to be harder to "get right" than encryption. This
despite the fact that signature schemes require only one-way functions, and
public-key cryptography seems to require something more...
-David
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Super-strong crypto......................(As if).
Date: Sat, 10 Mar 2001 00:36:54 +0100
"Douglas A. Gwyn" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> ? How could you mount a bit-flipping attack against a OTP system?
It is an active known plain text attack. Hijack the message before it
reaches it's destination and xor the plain text with the cipher text to get
the OTP. Then xor the OTP with a fake plain text of your choice, and send
that to the user.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Tempest Systems
Date: Fri, 09 Mar 2001 18:46:58 -0500
Lyalc wrote:
> Every state transition from a 1 to 0 or vice versa is detectable in some
> way, not always usefully so when you have some meters away from the unit.
>
> Screens, keyboards, printer port/cables, serial port/cables, hard disk
> drives (getting tricky), floppy drives, the on-off switch (it at least tells
> you the machine is on!), printer, modem, ethernet card etc
>
> Different by brand, model and implementation, so for a PC brand X look at
> screen and keystrokes info, while for brand Y look at printed data, screen
> and the network interface hardware.
> This is where the cost/complexity challenge to the attacker really starts to
> bite them.
>
> And no, I'm not aware of any 'by component' rating of the Tempest rating of
> workstation sub components, though this may exist somewhere. It won't be
> easy to build a low emanation machine by careful component selection, but
> theoretically possible.
>
> Lyal
>
> Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
> >
> >
> >Steve Portly wrote:
> >>
> >> 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.
> >
> >Dumb question: What are the major activities of a computer
> >that could be well monitored through electromagnetic
> >emanations? Thanks.
> >
> >M. K. Shen
Since most of the processes in a typical desktop computer work off the same
source of clock signals (through clock multipliers) it should be fairly easy to
discriminate most processes in the target computer from outside noise. I
remember watching my grandfather use his oscilloscope back in the 60's to
isolate circuit noise. The waves superimposed themselves on the screen in what
looked to me like chaos. He was able to see the slight offsets in the peaks of
the signals and identify what signal came first and what came second. By
shifting scope connections and using a little logic one could get a fairly
accurate picture of what exactly the circuit was doing. Since analysis of
electromagnetic emanations is such a mature technology, it is a little difficult
to speculate on all of the possibilities. Although my archaic example probably
does not scale very well you mentioned the use of superconductors in cell phone
tower noise filters some time ago, which speaks volumes about the advances made
in electronics since WW2.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: Sat, 10 Mar 2001 01:05:00 +0100
"Benjamin Goldberg" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Well, yeah. Noone is likely to do any better than the PGP system any
> time soon. They might, however, do better in terms of ciphers. The PGP
> system can, with little difficulty, be made to use whatever cipher you
> want. That's why noone intelligent says, X is better than pgp. They
> might say, Y is better than AES, and Z is better than RSA or ECC.
I haven't heard much but complaints about PGP from ordinary end users. They
find it too complicated, and don't like to mess with the security issues
involved in exchanging public keys with others. Someone ought to be able to
design an application better than PGP in these respects.
Besides that, you don't have to justify the existence of a security
application by claiming that it is better than PGP. It is usually sufficient
to claim that it attempts to address other security issues, or that it is
intended to be be used under more specific circumstances, and is adapted for
that particular purpose. For instance, if the system is such that you would
obtain the same security level with passwords instead of long term DH or RSA
keys, well, then loose the keys and settle for SRP or something similar.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2001 00:07:36 GMT
Daniel James <[EMAIL PROTECTED]> writes:
> There's also an interesting question of how you prove that you really are the
> owner/authorized user of the allegedly lost/stolen token when reporting its
> loss/theft ... and of how the service operating the 1-800 number proves to your
> financial institutions that you really did report the cards missing.
>
> CRLs should always be signed, to frustrate denial of service attacks.
>
> Cheers,
> Daniel.
yep, if you look at the "weakest link in the chain" ... with respect
to applying digital signatures & X9.59 to payment cards ... the
weakest link has been the ability to harvest credit card numbers and
use them in fraudulent unauthenticated transactions.
fixing fraudulent unauthenticated transactions with X9.59 ... then
possibly the next weakest link in the current infrastructure is the
lost/stolen business process. This weaknesss also applies to calling
up your local friendly CA and convincing them that your hardware token
containing your private key has been lost/stolen.
this doesn't detract from x9.59 being able to eliminate the harvesting
credit card exploit associated with using them for executing
fraudulent unauthenticated transaction ... it just says that fraud
will have to move someplace else.
at least the straightforward weakness in lost/stolen process is denial
of service ... as opposed to fraudulently obtaining value thru
fraudulent unauthenticated transactions. projected fraud costs from
issues associated with lost/stolen report issues are significantly
less than the current fraud costs associated with fraudulent
unauthenticated transactions.
note the CRL issue and whether or not they are signed ... are
independent of how can convince you local friendly CA that your
hardware token has been lost/stolen.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
** 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
******************************
