Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Yes, Diffie was one of the first, the first being some guy that worked for the UK government a few years earlier (early 70's). The ^ operator means the logical "and". And yes, I was trying to describe open/public key -- If there is a difference -- please explain. The third thing in the definition list should be asymmetric, I don't know how I missed that mistake. Sincerely, Christopher J. McKenzie [EMAIL PROTECTED] [EMAIL PROTECTED] (530) 297-6110 609 Anderson 161 Davis, CA ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Fri, Apr 26, 2002 at 03:08:17AM -0400, [EMAIL PROTECTED] wrote: > Chris, > > 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... ;) That confused me too, but I just figured I wasn't familiar with what Chris was talking about. ;) -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
begin Chris McKenzie <[EMAIL PROTECTED]> > I hate long threads to I'll cut some stuff out here. > > 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. yeah, but what you just described here is an open key crypto system, like gpg. and if by "key" you mean "that which unlocks the code", then you've exactly described a public key system. you tell people how to encrypt the package, but don't tell them how to decrypt it. in fact, isn't diffie one of the inventers of public key cryptography? > > - 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 morningthat 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. i'm not sure i want to think about whether public key systems are asymmetic or not. it's 8am and i just woke up... > 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. this clearly described DES and IDEA. > 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. should this have been asymmetric? what does the operator ^ mean? pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Friday 26 April 2002 03:00 am, ME wrote: > ... > Sorry if this offended. :-/ That was not the point. It was to bring humor > for other to laugh at my stupid statement, not as an unkind word to their > intelligent realization. I understood perfectly, but thanks anyway. ;-) -- Rod http://www.sunsetsystems.com/ ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, 25 Apr 2002 [EMAIL PROTECTED] wrote: > Subject: Re: [vox-tech] Linux's Vulnerability to E-mail Viruses > > On Thu, 25 Apr 2002, ME wrote: > > > On Thu, 25 Apr 2002, Rod Roark wrote: > > > Interesting, I never thought about that before. The "locking" > > > (and corresponding unlocking) could easily be done by xor'ing > > > against some string of pseudo-random characters that only > > > the encryptor knows how to produce. > > > > The most advanced encryption available is found when you use 2XOR > > (double-XOR) with your data and the same key. > > > > You also get a huge cost savings in performance, as some stes can be > > skipped and, 8 bit 2XOR is just as secure as 2048bit 2XOR (assuming the > > same key in both passes. > > > > (Tongue in cheek - biteing down hard.) > > > > (This would have been better posted April, 1,2002 ;-) > > > > -ME > > Ouch... Oh! Just so the other list members note, I was not making fun of the original poster! XOR-ing against a key with equal bit length to the number of bits being encrypted (so long as the key is not reused "as-is" has been used before as a form of encryption. (When shorter keys are used or the same key is used in this simple kind of system is one place where security can easilu breakdown.) (A shared secret equal in size of the message can be rather strong - especially for very long messages if the key is not easily predictable or brute-forced.) [For example, I'm Alice sending Bob 8 bytes of data that have been XOR-ed once against an 8 byte key (non predictable bit sequence). If the key is a shared secret between us (Bob and Alice) then even the best code crackers might have a tough time knowing what 8-bytes of intended content were actually sent. Of course, using an 8-byte key in repeating sequence to "encrypt" 100 Mb of text file data might be just a little bit weak. The comment about 2XOR was supposed to be funny, and not making fun of the posters! (It was their comment that reminded me of this.) What the poster described is often used to describe earlier encryption systems, and is often used as part of a step in modern data-hiding. Sorry if this offended. :-/ That was not the point. It was to bring humor for other to laugh at my stupid statement, not as an unkind word to their intelligent realization. Sorry, :-/ -ME -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-) C++$() U$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++> h(++)>+ r*>? z? --END GEEK CODE BLOCK-- decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
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=
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, Apr 25, 2002 at 06:51:46PM -0700, Chris McKenzie wrote: > Modern encryption, assymetric processes. On Thu, Apr 25, 2002 at 07:13:02PM -0700, Peter Jay Salzman wrote: # also, i could be totally way off base here, but i think you and mike # were talking about different types of "processes". i'm pretty sure mike # is familiar with reversible processes. i'm guessing he thought you meant # something that goes into a process table. (?) Chris, 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... ;) On Thu, Apr 25, 2002 at 06:51:46PM -0700, Chris McKenzie wrote: > me lock > you lock > me unlock > you unlock 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. - Does symmetric encryption require that sort of combination to work? (A.lock, B.lock, A.unlock, B.unlock) 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. btw: the '|' characters above are meant to be unix pipes not logical ORs ;) > 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. ... 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. 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. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, 25 Apr 2002, Rod Roark wrote: > Interesting, I never thought about that before. The "locking" > (and corresponding unlocking) could easily be done by xor'ing > against some string of pseudo-random characters that only > the encryptor knows how to produce. I suspect the statistics of this process would allow a significant fraction (on average half?) of the hidden bits to peek through... which doesn't sound very secure to me. > > -- Rod >http://www.sunsetsystems.com/ > > On Thursday 25 April 2002 07:13 pm, Peter Jay Salzman wrote: > > begin Chris McKenzie <[EMAIL PROTECTED]> > > > > > Sure, I wasn't trying to intend a pun, I just mispelled. > > > > > > Modern encryption, assymetric processes. > > > > > > Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I > > > wanted to send it to you. However, you live in some remote jungle where > > > you can't copy a key. But I don't want the item to be stolen along the > > > way. 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. > > > > hi chris, > > > > cool post. > > > > this isn't how modern crypto systems work, is it? this assumes that > > the "locks" commute. that for a given message A, a chris lock C and > > peter lock P: > > > > chris CA --> peter PCA --> chris C^(-1)PCA --> peter P^(-1)C^(-1)PCA > > > > but i can't actually unlock the software unless > > > > P^(-1)C^(-1) = C^(-1)P^(-1) > > > > i don't know much about modern crypto systems other than RSA type > > things. is this how they work? or am i reading too much into an > > analogy? I don't know much about them either (I just use them) but if P = peter's public key p = peter's private key C = chris's public key c = chris's private key and ptxt = decode( encode( ptxt, P ), p ) ptxt = decode( encode( ptxt, p ), P ) ptxt != decode( encode( ptxt, P ), P ) ptxt != decode( encode( ptxt, C ), C ) (critical assumptions) then ctxt = encode( encode( ptxt, c ), P ) encoded by chris is a secure message unencodeable only by peter using ptxt = decode( decode( ctxt, p ), C ) [...] --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thursday 25 April 2002 09:43 pm, nbs wrote: > Like those ebooks! Wait, no that was ROT13 not ROT26? > -bill! > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, Apr 25, 2002 at 08:47:34PM -0700, ME wrote: > The most advanced encryption available is found when you use 2XOR > (double-XOR) with your data and the same key. Like those ebooks! Wait, no that was ROT13 -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, 25 Apr 2002, ME wrote: > On Thu, 25 Apr 2002, Rod Roark wrote: > > Interesting, I never thought about that before. The "locking" > > (and corresponding unlocking) could easily be done by xor'ing > > against some string of pseudo-random characters that only > > the encryptor knows how to produce. > > The most advanced encryption available is found when you use 2XOR > (double-XOR) with your data and the same key. > > You also get a huge cost savings in performance, as some stes can be > skipped and, 8 bit 2XOR is just as secure as 2048bit 2XOR (assuming the > same key in both passes. > > (Tongue in cheek - biteing down hard.) > > (This would have been better posted April, 1,2002 ;-) > > -ME Ouch... ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, 25 Apr 2002, Rod Roark wrote: > Interesting, I never thought about that before. The "locking" > (and corresponding unlocking) could easily be done by xor'ing > against some string of pseudo-random characters that only > the encryptor knows how to produce. The most advanced encryption available is found when you use 2XOR (double-XOR) with your data and the same key. You also get a huge cost savings in performance, as some stes can be skipped and, 8 bit 2XOR is just as secure as 2048bit 2XOR (assuming the same key in both passes. (Tongue in cheek - biteing down hard.) (This would have been better posted April, 1,2002 ;-) -ME -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-) C++$() U$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++> h(++)>+ r*>? z? --END GEEK CODE BLOCK-- decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Interesting, I never thought about that before. The "locking" (and corresponding unlocking) could easily be done by xor'ing against some string of pseudo-random characters that only the encryptor knows how to produce. -- Rod http://www.sunsetsystems.com/ On Thursday 25 April 2002 07:13 pm, Peter Jay Salzman wrote: > begin Chris McKenzie <[EMAIL PROTECTED]> > > > Sure, I wasn't trying to intend a pun, I just mispelled. > > > > Modern encryption, assymetric processes. > > > > Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I > > wanted to send it to you. However, you live in some remote jungle where > > you can't copy a key. But I don't want the item to be stolen along the > > way. 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. > > hi chris, > > cool post. > > this isn't how modern crypto systems work, is it? this assumes that > the "locks" commute. that for a given message A, a chris lock C and > peter lock P: > > chris CA --> peter PCA --> chris C^(-1)PCA --> peter P^(-1)C^(-1)PCA > > but i can't actually unlock the software unless > > P^(-1)C^(-1) = C^(-1)P^(-1) > > i don't know much about modern crypto systems other than RSA type > things. is this how they work? or am i reading too much into an > analogy? > > > also, i could be totally way off base here, but i think you and mike > were talking about different types of "processes". i'm pretty sure mike > is familiar with reversible processes. i'm guessing he thought you meant > something that goes into a process table. (?) > > pete > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
begin Chris McKenzie <[EMAIL PROTECTED]> > Sure, I wasn't trying to intend a pun, I just mispelled. > > Modern encryption, assymetric processes. > > Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I > wanted to send it to you. However, you live in some remote jungle where > you can't copy a key. But I don't want the item to be stolen along the > way. 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. hi chris, cool post. this isn't how modern crypto systems work, is it? this assumes that the "locks" commute. that for a given message A, a chris lock C and peter lock P: chris CA --> peter PCA --> chris C^(-1)PCA --> peter P^(-1)C^(-1)PCA but i can't actually unlock the software unless P^(-1)C^(-1) = C^(-1)P^(-1) i don't know much about modern crypto systems other than RSA type things. is this how they work? or am i reading too much into an analogy? also, i could be totally way off base here, but i think you and mike were talking about different types of "processes". i'm pretty sure mike is familiar with reversible processes. i'm guessing he thought you meant something that goes into a process table. (?) pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Sure, I wasn't trying to intend a pun, I just mispelled. ok. I will give you examples for have and know. Being "carded" before buying alcohol is a process that requires you to have ID as opposed to buying anything else in which case it only requires you to have money. If you don't have it, money/id, whatever, then you cannot complete the process. Sometimes, having is not good enough however. For you ATM card, not only do you need to have the card but you need to know the pin to access your account at the ATM. This is so someone that has a pin and not the card or visa versa can't do top much (ideally). Computer login can be the same. I can restrict login to be from a list of friendly computers. So you have to first have access to the friendly computers then know the login on the system, simply having access to the friendly computeris not enough and simply knowing the login is not enough. Microsoft displays a horrible implementation of this with registration keys. Not only do you need to have the software but you need to know this long incoherent string of characters which you can get from most friends and easily with internet access. The .NET will eliminate one of these. After it is implemented then either the computer itself must be uniquely identified somehow as something you have or you must uniquely be identified somehow through fingerprints or something like that. This would be coupled with something you know, a login/password pair probably. Asymmetric/Symmetric processes. A Symmetric Process is something that is reversible, like a ball bouncing, if you reverse a video of someone bouncing a ball you might not be able to tell which way is forward and which way is backward. However if someone breaks some crystal on the ground then it is very distinct because crystal magically reassembling itself to some dove shape is not a normal occurance. And if you were to reassemble the shattered crystals (it is possible given a lot of time and effort) There would be only one way to do it. And a major clue of how to do it depends on what it looked like initially. In comes almost modern encryption Pretend that you had some fantastic device that could figure out how the crystal breaks and it some how magnificantly tracks every piece of the crystal, then you throw the pieces into this mystical machine and the crystal is reassembled. It would be easy to assume that the device for putting the crystal back together would be much more difficult then a device for taking it apart, say a hammer. This process is nearly-asymmetric. Although it is much more difficult to do the reverse it is still possible, and in fact, it is the same process in reverse as long as you know how it broke although a different procedure. An example of this in real life is a door. The magnificant machine in this case is something I have, a key. I put it in the lock and turn, simple enough, the door no longer opens. Some nefarious person comes along and uses some much much more sophisticated device and reverses the process. Because what I did is quite difficult to undo without something I have or know, it is somewhat secure. This is essentially how modern algorithms work. Modern encryption, assymetric processes. Alright, say I had a very rare piece of software, OpenStep 4.2/i386 and I wanted to send it to you. However, you live in some remote jungle where you can't copy a key. But I don't want the item to be stolen along the way. 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. By the same idea, I can come up with some very sophisticated lock -- one Dr Seuss would be proud to put in a book. I design it in such a way so that whenever you lock the lock the lock is designed in such a way that you need a different key to unlock it. Ah, this is the asymmetric part -- if someone wanted to unlock it, reversing what they just did was not enough because it is some mystical lock that must be unlocked by a different process. Thus I can give out these locks and the locking keys freely and say "if you want to send me anything throw my lock on it and lock it. I have the only key to unlock it". An example of an asymmetric process in nature is a chemical reaction. Say I throw two chemicals together and they bond and turn green. How would I seperate them? I definitely can't go in there and break the bonds by hand...more than likely, I may have to do something entirely different, say make the chemical some scorching temperature to get what I started with. Perhaps I may get three different chemicals as a result of this. Then I may have to combine two to get my original two chemicals 0 Symmetric is where doin
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Thu, Apr 25, 2002 at 04:23:30PM -0700, Chris McKenzie wrote: > Also, be aware > of symmetric versus assymetric processes and processes that require you > to have something or know something. Assymetric processes that require > you to have or know something are usually preferred. Chris, The two sentences above lost me. Could you explain a little more what context you are talking about... I've not heard the phrases: "symmetric processes", "assymetric processes", "processes that require you to have or know something"... Thanks, Mike my spell checker says "asymmetric" ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
The most famous e-mail "virus" of the 80's used the assumption that everyone was using the UNIX elm e-mail client, it was the famous XMAS tree and was headline news at the time. Generally speaking, *NIX networking software does not make as many fundamentally bad assumptions about the users. For example, in IRC, DCC auto-receiving of files is easy to enable and the LifeStages.txt.vbs is rampant. The main insecurity about a windows system with respect to viruses is I think two fold: First, by default, the final extension is hidden of a file. However, Windows uses this final extension to determine what to do with the file. Second, a mere extension changes a file type, so the noun-verb analogy works well, however, the verb is sometimes ambiguous -- especially when it cannot be implied. Although *NIX does not have these inherent security flaws, it does not mean that a user of this system is generally *safe*. Watching out for a virus in a computer is like watching out for sickness in real life. There isn't some boxed pill that you buy at a drug store, it is a lifestyle choice that leads to a healthier life. Similarly, securing yourself should be a proactive measure. Use checksums whenever possible. Also choose ssh over telnet when reasonable. Use sufficiently secure passwords and know what you are getting into before you get into it. Also, be aware of symmetric versus assymetric processes and processes that require you to have something or know something. Assymetric processes that require you to have or know something are usually preferred. On Wed, 24 Apr 2002, Richard S. Crawford wrote: > I'm operating under the assumption that while viruses for Linux that > spread like Windows viruses are very rare, there are still some out > there. > > So, given that, what level of vigilance is necessary against incoming > viruses in a Linux system? > -- > Sliante, > Richard S. Crawford > > mailto:[EMAIL PROTECTED]http://www.mossroot.com > AIM: Buffalo2K ICQ: 11646404 Yahoo!: rscrawford > MSN: [EMAIL PROTECTED] > > "It is only with the heart that we see rightly; what is essential is > invisible to the eye." --Antoine de Saint Exupery > > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech > Sincerely, Christopher J. McKenzie [EMAIL PROTECTED] [EMAIL PROTECTED] (530) 297-6110 609 Anderson 161 Davis, CA ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Wed, Apr 24, 2002 at 10:00:56PM -0700, Micah Cowan wrote: > On Wed, 2002-04-24 at 21:21, Richard S. Crawford wrote: > > I'm operating under the assumption that while viruses for Linux that > > spread like Windows viruses are very rare, there are still some out > > there. > > > > So, given that, what level of vigilance is necessary against incoming > > viruses in a Linux system? > > ...Linux has no problems of this sort, for the simple reason that nobody > has been stupid enough to write mail clients which are capable of > automatically running executables. I'm not sure I agree about open-software developers 'not being stupid enough to automatically run executables'... from the angle of most open-software programs have a few buffer overrun bugs and depending on exactly how the overrun is arranged many of these are as good as "execute the following machine instructions for me please", when in the hands of someone intimately familiar with the target environment. There have been a number of bugs in mail handling components which translate to automatic stack overflows in the the system. Bugs in fetchmail, procmail, and mutt all come to mind. Although I don't think any proof of concept demos where created. There are also some very user friendly email clients which, may not ship with the option on but, can be asked to automatically open files of certain mime-types with a specific program. If the processing program (like xpdf, mozilla, etc) has *ANY* stack overflow from input file style bugs this would also provide an automatic method into the machine for users of those clients. Until all programming switches to a languages or environments which remove overrun possibilities there will always be a risk. Later, Mike (java is *not* the solution... but perl might be ;) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Wed, Apr 24, 2002 at 09:55:22PM -0700, Richard Crawford wrote:
> I'd like to pass this on to another list that I'm on which is discussing
> just this issue. May I?
Richard,
Certainly.
Please leave my email address and authorship in whatever you forward
so people know who to contact about errors...
Later,
Mike
> On Wed, 2002-04-24 at 21:47, [EMAIL PROTECTED] wrote:
> > On Wed, Apr 24, 2002 at 09:21:12PM -0700, Richard S. Crawford wrote:
> > > I'm operating under the assumption that while viruses for Linux that
> > > spread like Windows viruses are very rare, there are still some out
> > > there.
> > >
> > > So, given that, what level of vigilance is necessary against incoming
> > > viruses in a Linux system?
> >
> > Richard,
> >
> > Short answer: don't read email as root, don't open attachments from
> > email ever, do update your mail handling system from time to time
> > especially if you heard about an exploit in some component you use,
> > and do think before you react to an email.
> >
> >
> > Email borne viruses fall into three main categories:
> >
> > - Vulnerabilities in your mail handing system,
> > (mail server, fetchmail, procmail, email client, etc...)
> >
> > Which typically stack overflow problems and should be very rare
> > and fixed by the upstream maintainers in a heart-beat once found
> > (sometimes quietly fixed) however these fixes get a fair amount of
> > publicity if found in the wild.
> >
> > - Vulnerabilities in your attachment processing system or programs,
> > (mail client auto-open-attachments, mailcap,
> >openoffice, abiword, gnumeric, etc...)
> >
> > A mailcap configuration _can_ be extremely dangerous, because you
> > can elect to do anything you want with a data stream based on it's
> > mimetype. If you pass a outside data stream to a vulnerable program
> > with mailcap or even manually you are at risk of any exploits against
> > that program.
> >
> > There are a large number of these holes which exist, and some
> > get created or closed every day. Basically any program you run
> > that can be feed an input file and crashes is a hole should not
> > be trusted with a mail borne data stream. Fixes are not generally
> > well published, as long as you stick to text based email you are safe.
> >
> > If you are doing mail as your own user the good news is you can
> > not damage the system, just wipe out the files owned by your user
> > account. This is until someone builds a super virus which would
> > get initial user access through an application vulnerability then
> > run a collection local-root exploits to take over root. This will
> > be front page news practically ever where.
> >
> > - Vulnerabilities in wetware processing the mail,
> > ("send to all your friends or else", "Make money fast",
> >"do X and your hair won't fall out"
> >save-to-file/change-to-file/chmod-to-executable/run-[as-root])
> >
> > There isn't much that can be done about these people, short
> > of turning on spam filters, education, or execution (depending
> > on your stance).
> >
> > TTFN,
> > Mike
> > ___
> > vox-tech mailing list
> > [EMAIL PROTECTED]
> > http://lists.lugod.org/mailman/listinfo/vox-tech
> --
> Sliante,
> Richard S. Crawford
>
> mailto:[EMAIL PROTECTED]http://www.mossroot.com
> AIM: Buffalo2K ICQ: 11646404 Yahoo!: rscrawford
> MSN: [EMAIL PROTECTED]
>
> "It is only with the heart that we see rightly; what is essential is
> invisible to the eye." --Antoine de Saint Exupery
> ___
> vox-tech mailing list
> [EMAIL PROTECTED]
> http://lists.lugod.org/mailman/listinfo/vox-tech
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Mike,
I'd like to pass this on to another list that I'm on which is discussing
just this issue. May I?
Richard
On Wed, 2002-04-24 at 21:47, [EMAIL PROTECTED] wrote:
> On Wed, Apr 24, 2002 at 09:21:12PM -0700, Richard S. Crawford wrote:
> > I'm operating under the assumption that while viruses for Linux that
> > spread like Windows viruses are very rare, there are still some out
> > there.
> >
> > So, given that, what level of vigilance is necessary against incoming
> > viruses in a Linux system?
>
> Richard,
>
> Short answer: don't read email as root, don't open attachments from
> email ever, do update your mail handling system from time to time
> especially if you heard about an exploit in some component you use,
> and do think before you react to an email.
>
>
> Email borne viruses fall into three main categories:
>
> - Vulnerabilities in your mail handing system,
> (mail server, fetchmail, procmail, email client, etc...)
>
> Which typically stack overflow problems and should be very rare
> and fixed by the upstream maintainers in a heart-beat once found
> (sometimes quietly fixed) however these fixes get a fair amount of
> publicity if found in the wild.
>
> - Vulnerabilities in your attachment processing system or programs,
> (mail client auto-open-attachments, mailcap,
>openoffice, abiword, gnumeric, etc...)
>
> A mailcap configuration _can_ be extremely dangerous, because you
> can elect to do anything you want with a data stream based on it's
> mimetype. If you pass a outside data stream to a vulnerable program
> with mailcap or even manually you are at risk of any exploits against
> that program.
>
> There are a large number of these holes which exist, and some
> get created or closed every day. Basically any program you run
> that can be feed an input file and crashes is a hole should not
> be trusted with a mail borne data stream. Fixes are not generally
> well published, as long as you stick to text based email you are safe.
>
> If you are doing mail as your own user the good news is you can
> not damage the system, just wipe out the files owned by your user
> account. This is until someone builds a super virus which would
> get initial user access through an application vulnerability then
> run a collection local-root exploits to take over root. This will
> be front page news practically ever where.
>
> - Vulnerabilities in wetware processing the mail,
> ("send to all your friends or else", "Make money fast",
>"do X and your hair won't fall out"
>save-to-file/change-to-file/chmod-to-executable/run-[as-root])
>
> There isn't much that can be done about these people, short
> of turning on spam filters, education, or execution (depending
> on your stance).
>
> TTFN,
> Mike
> ___
> vox-tech mailing list
> [EMAIL PROTECTED]
> http://lists.lugod.org/mailman/listinfo/vox-tech
--
Sliante,
Richard S. Crawford
mailto:[EMAIL PROTECTED] http://www.mossroot.com
AIM: Buffalo2K ICQ: 11646404 Yahoo!: rscrawford
MSN: [EMAIL PROTECTED]
"It is only with the heart that we see rightly; what is essential is
invisible to the eye." --Antoine de Saint Exupery
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Wed, 2002-04-24 at 21:21, Richard S. Crawford wrote: > I'm operating under the assumption that while viruses for Linux that > spread like Windows viruses are very rare, there are still some out > there. > > So, given that, what level of vigilance is necessary against incoming > viruses in a Linux system? Viruses for Linux exist, but are rare. E-mail viruses, as per your subject line, don't exist at all (yet). This is because Windows has default settings which will actively run any scripts embedded in HTML mail, which means that as soon as you read your email, that embedded script can run, say, an attached executable with massively destructive capabilities >:] >:] >:] ...Linux has no problems of this sort, for the simple reason that nobody has been stupid enough to write mail clients which are capable of automatically running executables. However, if you have an attachment which is some sort of script, or is a file which takes advantage of a buffer overflow, etc. it could still do damage if you have mailcap settings which will automatically run it or load it into an insecurely buggy program - that latter, however, is extremely unlikel - still, with the zlib buffer problem that was recently discovered, such things are certainly not impossible. So, the rule for Linux is basically the same as for Windows: never view attachments when you don't know the source. But, as to Linux viruses in general: the reason they are so rare is that they are not very effective unless the victim is unusually moronic. Because they can only do damage to things over which the victim has privileges. If you're an average joe-type user, the best it can do is wipe out your particular files. It can't touch anybody elses files, and can't screw up your system, generally speaking. Most of the "viruses" around today aren't really viruses at all - they're trojans, which require the user to run them as root (or at least a very priveleged user). Since root tends to be suspicious (hopefully) of strange programs, such problems are rare indeed. -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
Erm, well, that doesn't work right in kmail, but if your email client went by mime types, you'd see [ryan@bob ryan]$ ./diagram.gif Don't run suspisious attachments! On Wednesday 24 April 2002 09:45 pm, Ryan wrote: > You mean like email viruses? They aren't feasable, you'd have to post one > on a linux mailing list or something to get one passed around. > > See the attached diagram for more info. > > On Wednesday 24 April 2002 09:21 pm, Richard S. Crawford wrote: > > I'm operating under the assumption that while viruses for Linux that > > spread like Windows viruses are very rare, there are still some out > > there. > > > > So, given that, what level of vigilance is necessary against incoming > > viruses in a Linux system? ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
On Wed, Apr 24, 2002 at 09:21:12PM -0700, Richard S. Crawford wrote:
> I'm operating under the assumption that while viruses for Linux that
> spread like Windows viruses are very rare, there are still some out
> there.
>
> So, given that, what level of vigilance is necessary against incoming
> viruses in a Linux system?
Richard,
Short answer: don't read email as root, don't open attachments from
email ever, do update your mail handling system from time to time
especially if you heard about an exploit in some component you use,
and do think before you react to an email.
Email borne viruses fall into three main categories:
- Vulnerabilities in your mail handing system,
(mail server, fetchmail, procmail, email client, etc...)
Which typically stack overflow problems and should be very rare
and fixed by the upstream maintainers in a heart-beat once found
(sometimes quietly fixed) however these fixes get a fair amount of
publicity if found in the wild.
- Vulnerabilities in your attachment processing system or programs,
(mail client auto-open-attachments, mailcap,
openoffice, abiword, gnumeric, etc...)
A mailcap configuration _can_ be extremely dangerous, because you
can elect to do anything you want with a data stream based on it's
mimetype. If you pass a outside data stream to a vulnerable program
with mailcap or even manually you are at risk of any exploits against
that program.
There are a large number of these holes which exist, and some
get created or closed every day. Basically any program you run
that can be feed an input file and crashes is a hole should not
be trusted with a mail borne data stream. Fixes are not generally
well published, as long as you stick to text based email you are safe.
If you are doing mail as your own user the good news is you can
not damage the system, just wipe out the files owned by your user
account. This is until someone builds a super virus which would
get initial user access through an application vulnerability then
run a collection local-root exploits to take over root. This will
be front page news practically ever where.
- Vulnerabilities in wetware processing the mail,
("send to all your friends or else", "Make money fast",
"do X and your hair won't fall out"
save-to-file/change-to-file/chmod-to-executable/run-[as-root])
There isn't much that can be done about these people, short
of turning on spam filters, education, or execution (depending
on your stance).
TTFN,
Mike
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux's Vulnerability to E-mail Viruses
You mean like email viruses? They aren't feasable, you'd have to post one on a linux mailing list or something to get one passed around. See the attached diagram for more info. On Wednesday 24 April 2002 09:21 pm, Richard S. Crawford wrote: > I'm operating under the assumption that while viruses for Linux that > spread like Windows viruses are very rare, there are still some out > there. > > So, given that, what level of vigilance is necessary against incoming > viruses in a Linux system? diagram.gif Description: Attached diagram
[vox-tech] Linux's Vulnerability to E-mail Viruses
I'm operating under the assumption that while viruses for Linux that spread like Windows viruses are very rare, there are still some out there. So, given that, what level of vigilance is necessary against incoming viruses in a Linux system? -- Sliante, Richard S. Crawford mailto:[EMAIL PROTECTED] http://www.mossroot.com AIM: Buffalo2K ICQ: 11646404 Yahoo!: rscrawford MSN: [EMAIL PROTECTED] "It is only with the heart that we see rightly; what is essential is invisible to the eye." --Antoine de Saint Exupery ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
