Cryptography-Digest Digest #803, Volume #8 Sun, 27 Dec 98 10:13:01 EST
Contents:
Re: coNP=NP Made Easier? (Bryan Olson)
Re: Meditations on a Cordless Phone (Stephen Early)
Re: User Caused Scramdisk problem (Aman)
Re: Stego in jpeg files (Allan Latham)
ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev 0.6 available
(Allan Latham)
Re: S-Tools and PGP 5.5.3a? (Ian Harris)
Re: A review of Scramdisk (Sh)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: coNP=NP Made Easier?
Date: Sun, 27 Dec 1998 03:55:45 -0800
rosi wrote:
> Bryan Olson wrote:
> > Posts invite follow-ups. E-mail is the appropriate medium for
> > private discussions.
> Put the above two lines more appropriately to that ilias.
Uh, I can't parse that.
> Let me just ask you once more: Are you or are you not this ilias?
Uh, you haven't asked me that before, but all my posts
have carried my name, and it's the only name I've used.
> > There's no need to worry about Dr. Kastanas' concept versus Valmari
> > Antti's or Rune Bang Lyngsoe's or mine. They are the same in every
> > important way.
>
[...]
> I am very curious why you would like to say for other people?
It's a matter of understanding them, not speaking for
them.
> You have your opportunity to make it clear
> to the world in exactly what way 'they are the same in every
> important way'.
The differences are trivia such as whether the tape has
"Yes" on it upon termination, and whether the machine
can print "No" and terminate to indicate it doesn't accept.
These are unimportant in exactly this way: if there is
a NDTM under any of these definitions that accepts a
language L, there is obviously also a NDTM under the
other definitions that also accepts L, and in time that
differs by at most an additive or multiplicative
constant.
> So while waiting for a reply from this ilias, why don't
> you post your concept, notion, and the exact definition of such an M
> (NDTM? I really do not care in the least. As I said it can be a magic
> piece of rock). Just tell me, us, and the whole world how that works. I
> take whatever you come up and proceed with the discussion. I do not in
> the least believe you would have the courage to shy away from a few
> simple questions. :)
Magic rock? You don't care?
Here's what I've understood in the thread: You posted
an argument to show that CoNP=NP. The approach was to
present a construction such that given a NDTM accepting
language L in polynomial time, the construct would derive
a NDTM that accepts ~L (the complement of L) also in
polynomial time. That is a valid approach.
Unfortunately, your construction doesn't work, as a few
people pointed out. I thought Rune Bang Lyngsoe
presented a particularly good demonstration, by giving
an example of a polynomial time NDTM accepting subset
sum, for which your construct fails to yield a NDTM that
accepts ~SS in polynomial time.
If you decide to use magic rocks instead of TMs or NDTMs,
then you don't even have a valid approach.
> > I've adopted the same definition one finds in the
> > textbooks.
> >
>
> Very good! Let us just have a quote of your textbook(s) of the
> definition you use and will use for the discussion. I see that you
> wrote a lot and frequently to this news group (sci.crypt). You would
> not mind put in a few lines to copy the definition from your textbook(s)
> for us to read and learn and base upon for the discussion, would you?
I suppose I could. I don't really see why you can't
look it up yourself, or why you would have carried on
this far without doing so. But since people might
learn from it, here are quotes from Lewis and
Papadimitriou /Elements of the Theory of Computation/,
Pretice Hall, 1981. My keyboard doesn't have all the
symbols the book uses, so I'll use * for Cartesian
product, + for set union, and $ and D for the book's
sigma and delta respectively.
"Formally, a nondeterministic Turing Machine
is a quadruple (K, $, D, s) where K, $ and s are
as for standard Turing machines, and D is a subset
of (K*$) * ((K + {h}) * ($ + {L, R}))
(rather than a function from K*$ to
(K+{h})*($+{L, R})). Configurations and the
relations |-m and |-m* are defined in the natural
way. But now |-m need not be single-valued: One
configuration may yield several others in one step."
To fill in stuff the book defines in other places,
h is the halt state,
K is the set of states other than h,
$ is the alphabet (not containing L nor R),
s is the initial state
L and R are the pseudo-symbols that cause the
head to move left and right on the tape.
|-m is the single step configuration to
configuration relation,
|-m* is the multi-step relation.
Lewis and Papadimitriou go on to explain,
"Since a nondeterministic machine could produce two
different outputs from the same input, we have to
be careful what is considered to be the end result
of a computation by such a machine. We resolve this
problem by construction nondeterministic Turing
machines only as acceptors, so that the only
significant fact is whether the machine halts at all,
not what is left on the tape."
[...]
"As with all nondeterministic devices, there may be
several possible computations starting from the same
input; in order for the input to be accepted, it is
required only that some one of them result in the
machine halting."
Well, there it is. I'm assuming you know what a TM is,
and if not, please look it up.
[...]
> I once again repeat: I do not care if this M is NDTM or a piece of
> magic rock. I, for the questions asked of this ilias so far, want to
> just know --- and the simple commitment of this ilias (or yours if you
> do not think that my bringing this discussion down to a belew high-
> school level math is an insult):
> Does there exist such a mechanism that positively
> answers the SS question in FINITE time?
I know nothing about magic rocks. Of course a TM accepting
(or deciding) SS in finite time exists, as I've answered
twice before (and Dr Kastanas has also answered).
--Bryan
------------------------------
From: Stephen Early <[EMAIL PROTECTED]>
Subject: Re: Meditations on a Cordless Phone
Date: 27 Dec 1998 12:57:21 GMT
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Then, even higher up, are telephones using spread spectrum technology. I'm
>suspecting that the spread spectrum sequence may not necessarily be a
>secret one, so even at this level the security provided only comes from
>obscurity.
Are you talking about cordless phones that implement the DECT
standard? They are quite common, at least in Europe. The standard was
recently made available online; have a look around
http://www.etsi.org/
It isn't really spread-spectrum; it's a combination of FDM and TDM
using ten frequencies and twelve time slots (a simplification...) to
give 120 full-duplex 32kbit/s channels. The base station will choose a
frequency and slot to broadcast its beacon, which handsets will search
for. When a call is in progress the base station and handset measure
the signal quality, and may choose a different frequency and slot if
there's too much interference on the current one.
>Some top-of-the-line cordless phones do offer, as one Sony unit claims,
>"digital voice encryption". So the feature is available, but so far only
>in stratospheric models.
Annoyingly, details of the 'DECT standard encryption algorithm' and
'DECT standard authentication algorithm' (I'm not at a well-connected
site at the moment, so I don't want to spend time looking up the
proper names) are not available. This is a similar situation to GSM as
it was a few years ago. (ETSI is responsible for the GSM standard as
well, I believe.)
>In any event, a DES chip that runs at digital audio speeds is fairly
>expensive, and doesn't really belong in a consumer product that doesn't
>need it.
A standard DECT telephony channel is 32kbit/s in both directions.
>However, it would be nice if the base used a challenge-response protocol
>to verify the identity of the handset...
It does - this is documented in the publicly available part of the
standard.
The 'registration' procedure described in the manuals for handsets and
base stations generates a secret that is shared between the handset
and the base station.
Steve Early
------------------------------
From: [EMAIL PROTECTED] (Aman)
Subject: Re: User Caused Scramdisk problem
Date: Sun, 27 Dec 1998 13:18:30 GMT
On Sun, 27 Dec 1998 01:48:58 GMT, [EMAIL PROTECTED] (Red) wrote:
>Hope you can help:
>
>I attempted to create a scamdisk partition on D drive but aborted
>partway through the encryption process.
>
>The drive letter "e" was allocated to the part formatted drive.
>
>Both the original "d" and "e" drive show up in explorer but neither
>are accessable, with the error message -"unable to mount devise".
>In scram disk this shows up as Drive E
>
>I have successfully encrypted the original "d" drive and allocatted
>the drive as a "d". But if I try to revert this partition back to dos
>I get the unable to mount drives eror message and the drive is
>allocated a "e"
>
>My question - How can I revert back to dos on the original drive?
Reboot the machine, and that partition should not have any drive
letter allocated. The partition should be listed in the scramdisk
physical partition list.
You should then be able to revert to dos, as a format option.
You will need to reboot the machine after the partition dos disk
structure is recreated.
After reboot, check the partition type, in the list presented by
Scramdisk.
You should not format any partition bigger than 2Gbyte.
If your partitions are larger, use a container file instead.
Aman.
------------------------------
Date: Sun, 27 Dec 1998 14:20:52 +0100
From: Allan Latham <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Stego in jpeg files
Svenne Krap wrote:
>
> On Wed, 23 Dec 1998 14:31:24 GMT, [EMAIL PROTECTED] (R. Knauer)
> wrote:
>
> >On Wed, 23 Dec 1998 00:48:26 +0100, Allan Latham <[EMAIL PROTECTED]>
> >wrote:
> >
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>
> >>The first public version of a DOS program to hide a file in a jpeg
> >>file using techniques that obscure the hidden file from statistical
> >>analysis is available for anyone who wants to try it.
> >>
> >>http:\\pweb.uunet.de/flexsys.mtk/jphs01.zip
> >>
> >>please try and let me have your comments.
> >
> >Apparently the program istelf is hidden too.
> >
> >Bob Knauer
> >
> >"Laws to suppress tend to strengthen what they would prohibit.
> >This is the fine point on which all the legal professions of
> >history have based their job security."
> >--Frank Herbert
>
> Try making the last "s" into a "d" :)
>
> then it says
>
> http://pweb.uunet.de/flexsys.mtk/jphd01.zip
>
> Svenne
Congratulations! Hope you like what you found.
Allan.
------------------------------
Date: Sun, 27 Dec 1998 14:22:07 +0100
From: Allan Latham <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev 0.6
available
=====BEGIN PGP SIGNED MESSAGE=====
ppdd is an advanced encrypted file system for i386 Linux.
It is used in a similar way to the loop device and offers simplicity
and speed plus full strength encryption (128 bit).
The design takes into consideration the fact that data on disc has a
long lifetime and that an attacker may have the matching plaintext to
much of the cyphertext.
A combination of master/working pass phrases offers enhanced security
for backup copies.
Current status is BETA quality and comments on the
implemenation and underlying cryptography are most welcome.
The latest version allows root filesystem encryption thus ensuring
that no plaintext data can be accidently left on disc.
It consists of a kernel patch plus support programs and is not
intended for novices at this stage.
Available from: http://pweb.de.uu.net/flexsys.mtk/ppdd-0.6.zip
Various people have reported difficulty downloading .tgz files so the
latest version is now packaged as a .zip file which contains a .tar
and a pgp signature.
My pgp public key is available from: http://pweb.de.uu.net/flexsys.mtk
and from key servers.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQCVAwUBNoYjU+JCY/+xqTOxAQFrSgP/bYmxx4NX2852ZDYKKQxti0/2y71Hr34N
nkqA9WMwAunoqSvVUCqARmMpP43EJVBZwLDEhoMB0z32aCFdhyhV/5LKYrM4dcd6
ld23NaFtGlBGZoHcOG5+p/xUBTH9gEDKICA7JhE2Cwnn6W/IDMoABBDu72SmeLnm
tTLYSltkJZU=
=Wwzi
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Ian Harris)
Subject: Re: S-Tools and PGP 5.5.3a?
Date: Sun, 27 Dec 1998 14:01:58 +0100
Reply-To: [EMAIL PROTECTED]
Not sure about PGP, but S-Tools 4 can be found via the FTP search site at
http://ftpsearch.ntnu.no/
Search for s-tools4.zip
> S-Tools 4
> PGP 5.5.3a w/ RSA support
>
> Does anyone have these they can e-mail me, or give me a site URL that
> actually works? I've had so much trouble I wonder if these sites aren't
> somehow hindered from dispensing their downloads
>
> Thanks,
>
> KC
--
===========================================================================
Ian Harris EMail [EMAIL PROTECTED] or CompuServe 70374,3166
PGP 2.6.3i public key available on request
===========================================================================
------------------------------
From: [EMAIL PROTECTED] (Sh)
Crossposted-To: alt.security.pgp
Subject: Re: A review of Scramdisk
Date: 27 Dec 1998 08:42:01 -0600
On Fri, 24 Jul 1998 21:26:48 GMT, [EMAIL PROTECTED] (Lincoln Yeoh)
wrote:
>First, let me thank you again for the great job you did making such a
>program freely available (at perhaps some risk to yourself?). I hope you
>won't misunderstand and get the impression I am attacking you or your
>program. I'm all for useful improvements, we may disagree with what is
>useful and what is safe.
>
>On 24 Jul 1998 05:25:01 -0500, [EMAIL PROTECTED] (Aman) wrote:
>
>>Some code in the progam to reliably do the job, even surviving a reset
>>or power failure....... :)
>
>What I meant was just changing the passphrase and not changing the
>container secret key. The passphrase can be snagged easily, but ideally the
>container secret key should not be as easily snagged as currently
>implemented (pls see comments on .skf implementation below).
It can be done, but wouldn't allow revokation of skf files...
>
>I believe that changing the passphrase can be done reliably with low risk.
>
>If the container secret key is compromised by unauthorised creation of .skf
>files, the container secret key has to be changed by recreating a new
>container and copying the stuff over, deleting original, filling
>compromised container with large file, then wiping it, and then the
>container from existence.
>
>>But to merely change the passwords, via the key would be snake oil IMV
>>when you consider that the data to open the disk is exportable (with
>>different passwords), via a SKF file. Obviously the owner will know if
>>he's granted access to others, but will he remember it when he changes
>>his passwords ?
>
>In the current implementation, the owner will NOT know if he's granted
>access to others. As long as the .svl file is still mounted, and PC is
>unattended, anyone can walk over launch the scramble program, type in an
>skf password, save the .skf onto a disk, and that person can later mount
>the .svl container. There is NO need to retype the original passphrase at
>all!
To do so, would be snake oil. You would still be able to access the
critical data, anyway _if_ you knew how the program works, and
remember that the source code has been published....
The same person could walk over to your _unattended_ computer, copy
all the precious files out of the container onto a disk, and walk off
with them...... Moral.. don't leave the computer unattended, with
secret files mounted on a scramdisk volume....
However I take your point, that it would be perfectly feaseable to
read the data off all the mounted partitions (in its encrypted form) ,
and then collect all the passwords.... However I've a better idea to
_easily_ implement this:
Allow creation of SVL files only within a particular time within the
mounting.... So to grant access to 4 disks that have been mounted for
(say) 2 hours, you'd have to close them all, re-open them, and create
the SKF file within (say) 1 minute. That way you would have to
re-enter the original passwords. Bear in mind that modified software
would circumvent this however.
>
>I believe the container secret key should not be so easily snagged. Is
>there a way to hide and keep the secret key in ring 0?
>
All such data is in Ring 0 locked memory. However, under some
curcumstances it can be brought to ring 3. Which I'll amend.......
>In fact maybe export of the secret key to skf files or some other way
>should NOT be so easy. Compromise of just one .skf file and password would
>break it all.
>
See later......
>How about if the secret key is only in the container and ring 0 memory? For
>multi user access, perhaps 4 encryptions of the secret key can be allowed
>in a container. So up to 4 different passphrases per container.
>
It should be...
>I'd prefer to keep the secret key at a lower level. Right now it seems to
>be floating close to the top, and easier to skim off.
> With the secret key
>at a lower level, we'll have to rely more on passphrases, if the passphrase
>is compromised we change the passphrase. Whereas if the secret key floats
>up and is skimmed off we have to change the whole container.
>
>There are some interesting concepts of encrypting secret keys used in SFS
>by Peter Gutmann. The partial keys thing is particularly interesting.
>
>Of course Windows may be unable to keep the secret key safe in memory
>anyway, but I think we'll have to keep our fingers crossed in the
>meantime..
Which is why I wan't to device a safe form of disk re-encryption which
can be done on a regular basis, to revoke all SKF files, and to
re-secure the data.... Even then you've got to be sure your system
isn't spooked up.....
>
>>In the mean time, I've been concentrating on IMV more worrying
>>difficulties, such as Skin98 hooking the keyboard and monitoring
>>everything done by windows.....
>
>Yep. There are also hardware keyboard sniffers- plug the sniffer between
>keyboard and PC. Later retrieve sniffer and download the passphrases.
>
>I believe protecting yourself against such software may be extremely
>difficult.
>
Agreed. There isn't really any way it can be done......
>I did a patch to the DOOM Mouse spinner, to support the keyboard. So with
>just a keystroke them keyboarders could flip 180 degrees in DOOM. There
>were people actually claiming that only ID could do it, since DOOM took
>control of the keyboard interrupt etc blahblah. But I just got the mouse
>driver shim to read straight from the keyboard IO port.
>
>Could a background task poll the keyboard IO port directly? Wake up every
>1/50 sec or something. If it's possible, how can a program prevent that
>from happening?
Software probably could, if it was executing at Ring 0 not Ring 3
A good place to put this would be on an interrupt. But you could hang
code on the keyboard IRQ vector anyway...
Win95/8 "virtualises" the IO ports from Ring 3, so what you read from
a port isn't what you got on the _real_ io port.
>
>>Can anyone tell me when I can eat ? I am, after all working totally
>>alone on the coding of this _free_ software, with Sam handling all
>>the public issues such as liason etc.......
>
>Erm, feel free to eat :).
>
>>SKF file, (stored say on a floppy disk) with a much simpler password,
>>(or even none at all) and use _that_ to open the disk instead, by
>>dropping it on the Win32 app panel........
>
>Yeah that's what I don't like :). skf file with NO password.
Thats up to the user.
>
>Eat, keep your strength up. Long journey ahead :).
>
>Cheerio!
>
Regards,
Aman.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
