Cryptography-Digest Digest #902, Volume #13 Thu, 15 Mar 01 02:13:01 EST
Contents:
Re: OverWrite: best wipe software? (Dan Hargrove)
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: PGP "flaw" ("Mxsmanic")
Re: PGP "flaw" ("Mxsmanic")
Re: About one-time pad ("Mxsmanic")
Re: SSL secured servers and TEMPEST (Mark Currie)
Re: Instruction based encryption ("Michael Brown")
Re: PGP "flaw" (Brian D Jonas)
Re: One-time Pad really unbreakable? (Dave Knapp)
Re: Applications of crypto techniques to non-crypto uses (wtshaw)
Re: GPS and cryptography ("Greg Ofiesh")
Re: GPS and cryptography ("Greg Ofiesh")
Re: GPS and cryptography ("Greg Ofiesh")
Re: Crypto idea (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dan Hargrove)
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: 15 Mar 2001 04:12:25 GMT
>I do not understand the Dr.'s recommendations as you do.
>
>I believe he decided on these particular overwrite sequences because
>they address the particular peculiarities of legacy and modern hard
>drive write head drifts.
>
>If you use other random sequences of overwrite data and do not use
>these 27 sequences specifically recommended for his stated purpose
>then you do not necessarily exceed his protocol but in fact most
>probably diminish the effect of your overwriting.
>
>This is elementary logic which leads me to conclude you are hyping
>that other software in fulfillment of some sort of personal agenda.
Thanks for replying. Here is more of my recent conversation with Mr.
Tolvanen in alt.comp.freeware. After rereading the paper in question, I
saw that he was right.
From: [EMAIL PROTECTED] (Sami Tolvanen)
Newsgroups: alt.comp.freeware
Subject: Re: A freeware progie to ERASE data...
On 13 Mar 2001 23:29:15 GMT, Dan Hargrove <[EMAIL PROTECTED]> wrote:
>However, I distinctly recall (having read it yesterday) that Gutman's
paper
>says that for the random passes, real random data must be used, as pseudo-
>random data is too predictable, and can easily be stripped away.
Dr. Gutmann's paper doesn't say anything about the quality of the random
data
that should be used for overwriting, but it is said that cryptographically
strong random numbers are required for shuffling the passes:
: in fact we need to use a cryptographically strong random number
: generator to perform the permutations to avoid the problem of an
: opponent who can read the last overwrite pass being able to predict
: the previous passes and "echo cancel" passes by subtracting the
: known overwrite data
Using true random data for overwriting is not feasible, one would need an
external source of entropy for this. To quote Counterpane Systems' paper
on Yarrow pseudorandom number generator:
: Unfortunately, random numbers are very difficult to generate,
: especially on computers that are designed to be deterministic.
: We thus fall back on pseudorandom numbers. These are numbers
: that are generated from some (hopefully random) internal values,
: and that are very hard for an observer to distinguish from
: random numbers.
Here's a definition for cryptographically random data from the sci.crypt
FAQ:
: For a source of bits to be cryptographically random, it must be
: computationally impossible to predict what the Nth random bit will
: be given complete knowledge of the algorithm or hardware generating
: the stream and the sequence of 0th through N-1st bits, for all N up
: to the lifetime of the source.
If a pseudorandom number generator is cryptographically strong, it meets
the
requirements above, and in other words, even if you had N bits of output
from
the prng, you couldn't determine its internal state or the N+1st output
bit.
When applied to overwriting, the use of cryptographically strong prng makes
canceling the overwriting pass somewhat difficult.
>Is it possible to download random data and use it for the random passes?
If by downloading you mean getting random data over the web from a service
like this one (http://www.random.org/form.html), I wouldn't call it a real
possibility.
If we are using the overwriting method defined in Dr. Gutmann's paper, we
would need random data for eight overwriting passes. In order to overwrite
a
10Mb file, you would need 80Mb of random data - not something you'd want to
download each time.
However, using true random data for seeding a prng would be nice, but
transferring the unencrypted seed over the network would sort of defeat
the purpose of using a cryptographically strong prng in the first place.
--
Sami Tolvanen
http://www.tolvanen.com/sami/
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Thu, 15 Mar 2001 04:15:19 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:eD3ogpAqAHA.341@cpmsnbbsa09...
> What the TV lottery shows is that it is possible
> to have a situation that looks random enough to
> modern man that no one can successfully attack
> it at this time, or at least that a small enough
> percentage of people can attack it as to declare
> them moot in the overall scheme.
Well, since people working at the NSA and other spook agencies are human
beings like everyone else, if it's good enough for the lottery, it's
good enough for cryptography. I really don't think there are any
miracles happening inside the NSA; they are just better at some things
than are most other people--but that _is_ the NSA's business, after all.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: PGP "flaw"
Date: Thu, 15 Mar 2001 04:18:04 GMT
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
news:98orde$9qp$[EMAIL PROTECTED]...
> Yes, and now they have decided to no longer publish
> source code. Wonder whom they are protecting?
Themselves, or at least they probably perceive it that way. Most
companies believe that by keeping their source code confidential they
are protecting their intellectual property, and this is true to a
certain extent, although I think that, historically, publishing source
code doesn't necessarily help the competition as much as many company's
fear. At one time it was routine for software companies to publish
operating-system source code, for example, and that really didn't affect
the bottom line of the companies involved.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: PGP "flaw"
Date: Thu, 15 Mar 2001 04:19:20 GMT
"Tony L. Svanstrom" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You can't help but think about that - first a
> serious(ish) security problem is discovered,
> then a few months after patching that up they
> stop releasing the source code.
I think they are motivated by greed, not a desire to compromise
security.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: About one-time pad
Date: Thu, 15 Mar 2001 04:21:23 GMT
"Haka" <[EMAIL PROTECTED]> wrote in message
news:98olde$b0l$[EMAIL PROTECTED]...
> What do you think?
It sound work fine, but you must _never_ reuse any of the key bytes
("most of the time" isn't good enough, as reusing them even once makes
cracking the code trivially easy), and they should be as random as
possible.
Just using a more ordinary encryption like PGP would work just as well,
though, I should think.
------------------------------
Subject: Re: SSL secured servers and TEMPEST
From: [EMAIL PROTECTED] (Mark Currie)
Date: 15 Mar 2001 04:21:25 GMT
Hi,
A TEMPEST-hardened security module can be used which only allows the clear-text
private key to exist during a signature operation. At all other times, the
private key is encrypted with a long-term key that is protected with in
the security module's tamper-proof memory. This way the clear-text signatures
key/s never get broadcast in the way that you describe. All normal "production"
clear-text data is still transmitted to the security module of course, but
any long-term keys transmitted should be protected by an internal security
module long-term key.
Mark
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>I am not sure whether there is a better newsgroup for this, so please
>tell me if you know such.
>The problem is the following:
>Some websites (like retail banks) have a lot of traffic, which is
>secured with SSL. For each SSL session establishment (symmetric key
>exchange), the secure RSA key must be processed either by the CPU (or
>more likely) by a dedicated cryptographic coprocessor ("cryptobox").
>Heavily used sites will have SSL session establishment rates in the
>order of 100 per second. This means that the secret key is being
>"broadcast" as often as the CRT signal of a PC. Admittedly, the signal
>might be much weaker, but it is transmitted hundreds of thousands of
>times over a couple of days. Also, it will *always*be the same signal,
>contrary to a CRT signal.
>Even if one encases the cryptographic processor in a lot of metal, there
>must be a high-speed transmission link to the (web) server. To harden
>the crypto processor, a fiber cable would be used for that purpose. As
>power supply cables are always an emanation risk, the crypto processor
>would be powered from an accumulator inside the metal casing.
>Even with this kind of TEMPEST hardening, the signal will just be
>dramatically attenuated, as there is the hole for the fiber and the
>opening for the accumulator.
>The attacker could record the emanations for days or even weeks on
>broadband devices (essentially a farm of VCRs in a truck trailer) and
>then let the "square acres of signal processors" do sophisticated
>filtering on the recorded signal.
>These are my questions:
> -has anybody done some scientific considerations on this (maybe
>estimatic attenuation & jamming needs for cryptographic processors) ?
> -would salt water be a feasible strong attenuation medium (operating
>the crypto device in a salt water barrel) ?
> -are there any key usage policies *in use* to make this kind of
>attack impossible (such as temporary certificates signed with the
>"master" certificate of the site) ?
>
>
>
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Thu, 15 Mar 2001 17:30:33 +1300
First of all, thanks for all your great replies to my post.
This is a short list of things that need to be done to make the cipher (not
that I'm going to be doing any of them, as I'm trying linear cryptanalysis
on FEAL-4 to get a better idea of the method at the moment):
1) Stop the zeroing of the key-mashing
2) Somehow make sure the mashing doesn't get stuck in loops. This one ain't
gonna be easy ...
3) Add some sort of method to ensure that long strings of zeros don't get
sent to the encryption method. Maybe keep a checksum of the previous data
and add it or somehing ...
4) Make the initial key affect the whole cipher, not just the first 32 bytes
and the first key mashing.
5) Make the instruction table less linear. Maybe data dependant rotates etc
6) Impeach the cipher (Eliminate the zipper problem :)
7) Try and do something about weak keys
Maybe I'll just start from scratch ...
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: Brian D Jonas <[EMAIL PROTECTED]>
Subject: Re: PGP "flaw"
Date: Wed, 14 Mar 2001 23:16:13 -0500
The scary thing is that it took nearly 4 years to surface before being
corrected. And as a few of you mentioned, now the source code is not being
released. Keep in mind an OUTSIDE source delivered the news about the
"bug".
And it was quoted that the company was not pleased that they didn't keep
it
quiet. In other words, this was real close to never being heard of... And
in
the event we never heard about it, would it be fixed now?
And with the source code not being published, how does one know there
aren't
other "flaws" ?
The reason I am on this so much, is that I have spent the last 8 months of
my college free time writing an encryption e-mail client. PGP would
obviously be an alternative to my program. These are reasons why someone
would not want to use PGP, but instead perhaps use my program (not that
there is a direct comparison). However, PGP is obviously the major player
here. With 10mil users out of 400mil on the net, they are the microsoft of
the encryption world.
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Thu, 15 Mar 2001 05:15:23 GMT
On Wed, 14 Mar 2001 03:47:18 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>Tim Tyler wrote:
>>
>> Dave Knapp <[EMAIL PROTECTED]> wrote:
>> : On Fri, 9 Mar 2001 10:59:32 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>> :>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>>
>> :>A deterministic theory has no place for randomness.
>>
>> : Wrong. Thanks for playing, though. The many-worlds hypothesis (it
>> : isn't a theory yet) is deterministic, but it is unable to predict
>> : the results of a single observation, since the worldline in which
>> : the observation will be made is unpredictable.
>>
>> Actually many worlds does make concrete predictions if the initial
>> state is completely known. That's a consequence of its determinism.
>
>I think you're parsing that wrong. Knapp said "the wordline in which
>the observation will be made is unpredictable." You seem to be
>interpreting that as "the worldline will be unpredictable." I would
>interpret it as "it is not possible to predict which worldline the
>observer will be in, after the observation is made."
That is indeed what I meant. I can see how it could possibly have
been taken the other way.
>> Consequently, DAG's statement that: "It's not due merely a lack of
>> more detailed knowledge of the state of the system" is mistaken - if
>> sufficiently detailed knowledge of the state of the system were
>> available, prediction would be possible.
Only for the worldline in which the observations would be made, but
since you don't know which one it will be, it's kind of moot. Don't
confuse the many-worlds version of determinism with the "hidden
variables" attempt to explain QM. It doesn't work without violating
causality.
>To God, many-worlds is both deterministic and predictable. To man,
>many-world is deterministic, but not predictable. Determinism doesn't
>change based on who or what the observer is, but predictability does.
A very concise way to put it.
-- Dave
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Applications of crypto techniques to non-crypto uses
Date: Wed, 14 Mar 2001 22:51:24 -0600
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
> >
> > [EMAIL PROTECTED] (wtshaw) wrote in <jgfunj-1303012029190001@dial-244-
> > 015.itexas.net>:
> >
> > >Consider the usefulness of converting text to a sequence void of
> > >double characters, or a series of different tones, each of which is
> > >ended with one of another frequency.
>
> Tones? Like music? In a case like that, simply use one more tone than
> you have symbols. For 8 symbols, use 9 tones. If the current tone
> being played is x (x in 0..8), and you want to transmit symbol y (y in
> 0..7), switch to playing tone ((x+y+1) mod 9).
>
For tones, since A<->D converters exist, equipment using any range of
tones could be used for n-1 characters. I like the idea of 12 basic tones
from any octave converting to 10 digits and a space character.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: "Greg Ofiesh" <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Wed, 14 Mar 2001 22:15:45 -0800
I think everyone was expecting that the recipient would know where to go to
decrypt, therefore they would know what the numbers should be. So your
question then begs another: How does one know when they are where they
should be to decrypt? Or are they suppose to roam the countryside looking
for the message to decrypt?
"br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> How could you know the data before faking?
>
> Tom St Denis wrote:
> >
> > "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > > It's impossible.
> >
> > How so? Why can't I just fake the data coming into the machine?
> >
> > Tom
> >
> > >
> > >
> > > Tom St Denis wrote:
> > > >
> > > > "br" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > > > > What do you think about using Global Positionning System (GPS) as
key
> > to
> > > > > encryption?
> > > > > You can read a message only if your computer is a pre-defined area
or
> > > > > point in the earth.
> > > > > I'm waiting for comments
> > > >
> > > > What if I fake my position?
------------------------------
From: "Greg Ofiesh" <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Wed, 14 Mar 2001 22:17:32 -0800
So you are saying that your GPS location is your public key. Then the
question is how do you know if you are the one the message was intended for?
If I encrypt a message for you based upon your GPS location, then I must not
reveal that the message is for you lest others know how to decrypt it.
"br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> The recipient own the GPS and is in position that allow him to read the
> message.
> It's very simple.
> How could you know all technical features of my GPS?
> The software include some data about technical features of the
> recipient.
> Whithout those data and the real position no one can read the message.
> It's not hard to design the system.
> Try to imagine that every computer is unique.
> Try to find a relation between this unicity and the key to decipher the
> message.
> GPS is just a component of the system.
> You can use the phone of the recipient as key (not the phone number).
> Than means that every computer is described by stable technical
> parameters.
> So the computer X cand read only messages sent to it.
> If you don't own the computer X with its hardware components, it's
> impossible to read any message.
> How to communicate all parameters?
> Via network.
> I have invented unbreakable system to communicate safely via network.
> I'm going to publish it this groupnews.
> I'm trying to write it in english. A french version is still not
> complete.
> I'm french speaking.
>
>
>
> Tom St Denis wrote:
> >
> > "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > > How could you know the data before faking?
> >
> > How does the legitimate receipient know?
> >
> > Tom
------------------------------
From: "Greg Ofiesh" <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Wed, 14 Mar 2001 22:23:03 -0800
"Frank M. Siegert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 12 Mar 2001 21:16:22 -0400, br <[EMAIL PROTECTED]> wrote:
>
> >More hard to find out : the position of receiver.
> >I send a message to alice with his exact position as key.
> >k= f(positionGPS)
> >You can imagine any complex fonction.
>
> So you just want to use the position of the receiver as a key. There
> is no need for GPS then as the sender must know the receivers position
> in advance, so it is the same as if Alice and Bob agree on a private
> key (or for a moving receiver - a set of) before communication starts.
Not quite. In this case, I think he is suggesting that the sender has a
category of private keys that are actually public information. I don't see
how someone can know that a message is for them without identifying the key
to be used to decrypt it. So publicly cateloged secret keys is just as
effective - I mean, ineffective.
>
>
> About your first message: Anyone can read any message as long as
> he/she knows the receiver position (the key) and fake it. No 'complex
> function' will change this.
>
> You can however use the GPS signal as a source of entropy, but that's
> a different matter.
>
------------------------------
From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Thu, 15 Mar 2001 08:58:17 +0200
br wrote:
> Cryptanalysis use dictionaries as way to find a solution. They suppose
> that the clear message is wrote without spelling mistakes.
> I can write a message like "I love you" as " Ay lov u" or "Ilovu"etc....
> So how cryptanalists could know before my specific spelling of I love
> you.
Couldn't you just translate the message into another language? I think the
effect is the same. This way you would also get rid of generating spelling
mistakes and misunderstandings in the receiving end would be avoided. Not very
good encryption, though.
-- Panu H�m�l�inen
------------------------------
** 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
******************************
