l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2002 Apr 26 08:48

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Linux's Vulnerability to E-mail Viruses



I hate long threads to I'll cut some stuff out here.

>   Okay, Pete was absolutely correct, the rest of your email was talking
> about software programs, then switched context to encryption without
> using the word encryption, so I was trying to figure out how a executable
> was safer being asymmetric...  ;)

Yeah sorry...I was trying to speak in abstract without relating directly
to a computer

>   That is an novel method of secured transmission that would not
> have come to mind and I ditto Pete's question...

> On Thu, Apr 25, 2002 at 07:13:02PM -0700, Peter Jay Salzman wrote:
> # this isn't how modern crypto systems work, is it?   this assumes that
> # the "locks" commute.

Well I took the idea from an old book I read, I think it was by Diffie ...
The idea is to avoid transferring of keys.  In some older system there may
be some very tricky clever method of encrypting data and the same code
encrypts and decrypts it.  Therefore these codes are very valuable.  How
do I get them to you?  Well I send some big hefty armed guy with a
suitcase locked to his wrist to deliver it to you or something like that.

The asymmetric nature eliminates the need for a key exchange.  I can give
you the encrypt key, and it will not help you decrypt what you encrypt.


> - Does symmetric encryption require that sort of combination to work?
>   (A.lock, B.lock, A.unlock, B.unlock)

Symmetric _encryption_ is defined mathematically somewhere and I think it
is out of the scope of my concentration but if you are fluent in mathlish and
read proofs as you have breakfast every morning that I encourage you to
hunt it down.  As for you argument above, I don't think it is symmetric
simply because the undoing of the process is not the reverse of the actual
doing of it.

>   Something like (gzip | bzip2 | gunzip | bunzip2) would fail miserably
> at the gunzip stage... come to think of it even
> (rot13 | bzip2 | rot13 | bunzip2) wouldn't work... I think that scheme
> requires all locking methods involved to have that can be combined
> attribute.

No, I think that they are nearly-assymetric.  gunzip does not require you
to have or know, and it is essentiallt the same process different
procedure.

Difference between a process and a procedure is pretty much the following
The process of shattering a crystal can be done by the procedure of things
like hitting it with a hammer or throwing it on the ground, you are still
doing the process of shattering, just a different procedure.

In computer terms, it may be like a template in c++ but not exactly.
Another stab:
sorting will sort something no matter what you tell it to
sort, it is
really the same process, the process of sorting, just a different
procedure based on the data structure.

> > So I put a lock on the box and send it to you.  You can't open that
> > lock so in a ridiculous notion, you put another lock on it, one that you
> > have the key for and send the doubly locked box back to me.  I unlock my
> > lock but the box is still locked by you.  I send it back, and you unlock
> > your lock and have the software.
>
>   For physical world stuff I don't understand why you wouldn't just lock
> the explosive box with some new random lock, ship the box to the person.
> Then once you know they have the box, ship them a copy of the key... you
> are always risking interception and destruction of the item during
> first shipment.

Ok here is the problem: I send you the key, the key is something I have,
it is authentication.  I am letting go of my authentication token.
therefore anyone can authenticate themselves as me with the key for the
sake of the box.  However, if I hold on to my key and if you hold on to
yours then the authentication is perserved.

>   ... and while I'm thinking about it, it seems like it would be more
> straight forward in for the end receiver to send you the lock (for
> which only he has a key), you apply the lock to the explosive package
> and ship it, the receiver then uses his key to unlock.

Symmetric example:

In order to secure my food while camping I tie a bunch of tricky knots
around my food bag.  However, some ingenious gypsies come by and do
EXACTLY the opposite of what I did and the knots are unlocked.  They need
no authentication to do so.  They don't need anything but the security
measure itself and knowledge of the system.

The distinction between nearly-asymmetric and symmetric is not always an
easy one and I wish I could buffer it with a nice formal definition.  I
can sure try:
Given a set of values m that go through a transformation n=[A->B]m, a
process
is symmetric if
	1. The Operations of the transformation B->A are valid
	2. The Operations of the transformation B->A are identicle to A->B
Corollary: This would imply that m=[A->B]n ^ m=[B->A]n.

A process is nearly asymmetric if
	1. The operations of the transformation B->A are valid
	2. The operations of the transformation B->A are not identicle to
A->B however, m=[A->B]n ^ m=[B->A]n.

A process is symmetric if
	1. The operations of the transformation B->A can be valid, so long
	as if m=[A->B]n then m != [B->A]n.
	2. To get from n back to m will involve a process D->C which is
not identicle to A->B or B->A but will still yeild m.

I think that is complete and I hope it is correct -- I don't have any
bibliography to back me up -- if anyone is a math major maybe they can
correct me where I am wrong.

>   This second thing is basically what is public key encryption amounts
> to, and you were trying to explain symmetric systems... so I still don't
> understand symmetric, but now I know you are talking about encryption.
>
>     TTFN,
>       Mike
>
> I think in the physical world you a problem:
> - I want _this_ to get to _you_.
>
> In the electronic world it's different:
> - I want _only you_ to be able to get _this_.
>
> to explain the use of explosives above, my understanding of encryption:
> ==========
>   To draw on a physical world analogy, encryption is a lock box that goes
> around something.  This lock box has two very interesting properties:
> - some explosives such that if people tamper with the box it implodes
>   so they can't get the contents inside without being bomb experts :)
> - a little magic button on the lock box that when pressed the box
>   perfectly replicates itself and it's contents so people can try
>   lock-picking the box for years if they have the motivation.

Sincerely,
	Christopher J. McKenzie

	cjm@ucdavis.edu
	mckenzie@cs.ucdavis.edu
	(530) 297-6110
	609 Anderson 161
	Davis, CA

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!