Prudential uses it (partly for its logging facilities, partly for its ACLs, partly because they know that they can control what information is shown to/used/dealt with/modified by any part of their business).
Philips uses it for internal workflow and business intelligence.
There's a middle ground between "entity" and "communications." Yes, it is very difficult to verify that a certificate is being issued to the entity "Bank of America," but it should not be hard to verify that you're issuing a certificate to the domain name www.bankofamerica.com. And the latter is all you need to protect against MITM.
No, it's not. Mozilla knows of at least one instance where a user on a public wifi network had communications with a TLS-secured site MITM'd, and she allowed it by creating a security exception for an unknown CA that issued a certificate to CN=*.
Comodo's "authorityInformationAccess" only provides an OCSP responder URL, not a CRL. Apple's Keychain doesn't really handle OCSP by default (you have to go into Keychain Access, go to properties, go to the Certificates tab, and select OCSP: Best Attempt).
However, that's a "soft fail" mode, and if you block the OCSP responder host, it'll still allow it both in Firefox and Safari.
Mozilla and MS have made it as difficult as possible to inspect the certificate. Safari (and Apple's Keychain Manager) make it easier, but it's still a lot of information to try to digest.
I wish you'd put your two cents in on the dev-tech-crypto@mozilla.org mailing list.
Right now, they're avoiding removing the trust bits because that would essentially mean 3 months of not being able to authenticate Comodo certificates. They claim that it's because they don't want to inconvenience the end-users, but I tend to think that they're doing it because they've been paid not to.
SSL (now TLS) does allow certificate-less operation, and has since SSLv2. In that case, the key agreement is done via ephemeral Diffie-Hellman (DH without any static/attested key).
Why do you think Microsoft stopped trusting external CAs for its updates in Vista? It runs its own in-house CA at this point, and that's the only CA that can issue certificates that can sign updates for Windows.
1) Provide a means and place for people to apply what they learn in class (simple webspaces, simple CGI on Apache) 2) Provide a means and place for people to learn about things they won't learn in class (WebDAV and deployment of Flash and real-world security policies) 3) Try to contact Microsoft and IBM to see about getting free copies of their software to make available for your group (as well as quotes on exactly how much they would cost if they were sold to real-world businesses), and if you have an academic advisor get them to make the inquiry for you. 4) More than anything else, become a means for students (and possibly people in the community who need help) to get the things that they need to get done/done/.
Take on the challenge of finding local nonprofits that need websites, and then find students (or teams of students) who are willing to take on those needs. Better yet, see if you can provide a list of site requirements to a web development instructor, or get the various parts of the faculty to look to you for real-world projects for their students' portfolios. (A web developer, say, to code it; a graphic-arts-for-web major to do the imagery; a back-end database guy to get real-world understanding of what the various database metrics actually mean; a project manager, to make sure everything gets done...)
Perhaps you could even go so far as to get something offered through your organization an independent CS course number for independent work.
Realistically, you know you need to make your organization non-redundant. I'm inclined to agree with the "college DJ" thing (especially if your college doesn't have a radio station, it'd be possible to build a netcasting system that would at least be available to people on your college network); I also agree with the ipv6 bridging idea (if you need an ipv6 tunnel provider, you can always email ipv6 at research.earthlink.net -- that's where I get my home tunnel from).
You have resources. You realize that your resources are being duplicated. Now, your job is to figure out how to keep your resources relevant. (I wonder if you could get business credit for trying to overhaul this -- you're basically doing what a CEO needs to do when faced with an increasingly competitive marketplace and the need to reinvent the organization.)
I dunno if anyone's actually looked at this, but it's a lot worse than "requires physical access". For example...
1) Any program running on your system automatically can run AppleScript. 2) Any system configured to do load sharing via Xgrid can have commands injected that will do this sort of thing. 3) Anyone who can access the machine from remote can do it, including via VNC.
osascript -e 'tell app "ARDAgent" to run shell script "chmod -r ugo-rwx/System/Library/RemoteManagement/ARDAgent.app"'
but re-run it after doing any kind of "repair permissions" on the volume.
PGPFone was a wonderful idea. The protocol it used was messy as all hell. I talked with Phil about it in 1997; he said that it wasn't being maintained because it didn't lend itself to being extended to actually use participants' PGP keys (instead of just "I hear this voice" authentication), and that at that point all rights to it were owned by the company that had just purchased PGP Corporation.
Re:Hmm, not sure about that one
on
Abusing the GPL?
·
· Score: 1
If I'm correct, the copyright statement is the (Copyleft 2002 by [person doing the copyrighting], released under the GNU Public License v2 [or, at your option, any later version]) thing?
If I remember correctly, if you wish to claim copyright protection, you must include several things:
1) The word 'copyright' (the (C) or (c) notation does not work); 2) The year of the work's release or creation; 3) The person (natural or corporate) asserting copyright.
This can be followed by "All rights reserved", which means that you are granting no rights except the right to obtain the copy to the person who's obtaining the copy. Or, you can specify a license for it all.
However, if you modify a GPL'd piece of software, you only own the copyright to the pieces that you wrote yourself -- therefore, you must still maintain the copyright notice from the original author, or else you're committing plagiarism (removing a signature and rereleasing == claiming that you wrote it).
Yes, you must retain the LICENSE (or LICENSE.TXT) file -- but you also must preserve the original author's copyright statement. (Unless it says "copyright abandoned" or similar.)
Re:Obfuscated source code is not GPLable.....
on
Abusing the GPL?
·
· Score: 1
Actually, this is what 'discovery' is for. As soon as a lawsuit is slapped on, the lawyers get to go through a process where -everything- to do with the company's practices (including, but not limited to: the source code repository as of the date the lawsuit happened, as well as up to the date of the trial; any internal memos; any internal emails; any emails on developers' personal machines at home; any projected revenue statements; -anything- that at all has to do with the case at hand) regarding what they're charged with violating must be handed over.
Any company that is shown, in open court, to -not- be using at the very least CVS and more likely one of the larger source code revision tools will suddenly become the laughingstock of whatever industry they're trying to market software to... because what happens when old versions have bugs found, and need fixes without upgrading to the newest, slowest version? It also opens them up to lawsuits from shareholders, for not taking reasonable precautions (not performing due diligence) to maintain and grow the value of the stock in the shareholders' hands. Therefore, most companies won't have a lack of a development tree for revision control.
I thought one of the points of the DMCA was that reverse-engineering for the purpose of creating a compatible implementation was specifically a defense?
Regardless, the reason this got to court in the first place was because of the -violation of the license agreement- of the software player they found the unencrypted key from. The obvious rule would be, in this instance, that "you cannot be bound by any contract that you sign that would limit your legal protections". (Especially in California, where such is specifically prohibited by law.)
Keystone, at http://www.stonekeep.com/, is a PHP and MySQL/PostgreSQL/Informix-based helpdesk system that I'm finding very helpful in my job. The configuration is a bit hairy, but everything after initial configuration can be done through the web interface. Very slick.
Very, very interesting question. Essentially, we've got a situation where two different precedents exist: 1) Corporations can claim that the volume of the data passing through their services is such that tracking and maintaining its proper existence would place undue hardship upon them. They get cited as 'common carriers' in this case. 2) Individuals are -always- responsible for what their software sends out, and the 'common carrier' rule doesn't apply. (side note: I'm not sure what happens if a virus sends out pornography, who's responsible for it.) Hypothetically, it might be a good idea for the Freenet project to register as a corporation (non-profit would be better), and then make server operators 'members' of the organization. This would indemnify individual operators from the actions of the software that is required for membership. But, I don't know what the effect on the project itself would be. -Winged
I first ran into MainSoft when I needed a UNIX version of Visual SourceSafe. It appeared to do what I needed it to do (access repositories stored on a UNIX box, shared via Samba, between Windows and UNIX), and so my company bought it.
So I get called by a sales director, and we get to talking about this. (This was in April of 1999, btw.) I tell him that I'd -really- like to get my hands on a version for Linux, since that's where we were doing most of our coding. His answer was rather surprising... (Not a direct quote, but as much as I remember.)
"We haven't put any significant resources into Linux because we haven't had the demand for it. We would end up losing money on the porting. SourceSafe uses our MainWin library, and that's not ported right now, because developers don't seem to want to target Linux. We are, however, taking note of the number of requests, and it's quickly approaching critical mass."
Yes, I know, it's Marketing speaking, and Engineering is always a few months behind. But still.
He also gave some rather interesting insights into SourceSafe. He said that they got the source for SourceSafe 5 from Microsoft, and they ended up having to fix a lot of bugs in it. They did send the fixes back to MS. Anyway, they'd been promised the source for SourceSafe 6 a long while before they actually got it -- two months. They recommitted the resources they were going to use to do the port a couple of weeks before they actually got the source... and by then it was too late.
MainSoft has been one of the nicer companies I've ever had the pleasure of doing business with, actually. I do hope they succeed. (And they don't even, unlike MS FrontPage's Apache extensions, require root privilege to run!)
As I learned a couple of years ago: People do what they feel is -right-. If it appears to be evil, it's only because the action is somewhat short-sighted.
Confidential is a type of 'okay, the public shouldn't know this, but it doesn't hurt anything if they do find it out'. Secret is where 'the public is NOT to know this'. Top Secret is where 'even those people we trust with a Secret clearance are not to know this'.
On top of this, Confidential -should- not be shown to anyone outside of the need-to-know group; Secret and Top Secret -cannot- be shown to anyone outside the need-to-know group.
(Sorry, I just applied for a position at Rand not too long ago, and their network has an unclassified portion and a Secret portion. Anyone else ever read the Rainbow books?)
The only problem with most of this debate so far is that it's next to meaningless. The question was to ask if there were any initiatives to make Internet-based voting workable in the USA. As far as I know (which isn't much on the political side), no, there aren't.
However, this doesn't mean that it can't be done. <pulls well-thumbed copy of Applied Cryptography, 2nd Edition down from its shelf> Chapter 6 in this book has a bunch of 'Esoteric Protocols', including 'Secure Elections'. I'd wholeheartedly recommend anyone doing any research into this field to get this book.
In a nutshell, there are at least 6 (and sometimes more) different requirements for a protocol that can be used for secure voting. These are:
Only authorized voters can vote.
No one can vote more than once.
No one can determine for whom anyone else voted.
No one can duplicate anyone else's vote (meaning, they can't just say "okay, I'll just make it easy and vote the way Bob did over there").
No one can change anyone else's vote without it being discovered (and invalidated).
Every voter can make sure that his vote has been taken into account in the final tabulation.
Some schemes can also have another requirement:
Everyone knows who voted and who didn't.
There are very simple voting protocols, and the book describes the reasons these protocols don't meet the aforementioned requirements. (Some of these fall prey to the 'clipper chip' paranoia... "ohmigod, the government (or 'my party', etc) can figure out that I didn't vote for them!!!". Since voting's supposed to be -completely- anonymous from the time you're in the booth to the time you're not... I see this as a valid concern.)
There's a lot of useful things to be found in this book, and again, I wholeheartedly recommend it. There's undoubtedly been more research done in the 4 years since it was published; however, I've not been keeping up on that portion of the literature.
References:
_Applied Cryptography_, 2nd Edition, by Bruce Schneier, ISBN 0-471-11709-9. pp. 125-134. http://www.counterpane.com
Some of the above was taken directly from the book. Since I don't know HTML well enough to be able to format this the way it's supposed to be formatted in that case, please don't complain about my lack of proper formatting.
How many people actually USE the cryptoAPI? It seems to me that unless you're using this stuff, all of this has no effect.
Unfortunately, everyone who has PGP 6.0 or higher (including the International version) without buying the RSA add-on, and the 128-bit high-security package from Microsoft. Not to mention everyone who uses MSIE.
Specifically, PGP 6.0 and higher use CryptoAPI to provide backwards-compatibility with RSA-signed/encrypted PGP 2.x messages, allowing them to be decrypted and encrypted to. (Unfortunately, this screws the security model a little bit, because since it can only generate a Diffie-Hellmann keypair, the 2.x recipient can't verify the signature.)
When an API is invented, people start using it. Once people start using it, it's dangerous. Ergo, creating an API that has backdoors is dangerous. Period.
Providing technical assistance, AFAIK, is considered a type of export. Since this law deals with "ideas" as a valuable commodity (hmmm, if this is the case, why can't you copyright or patent ideas, only implementations?), you can't even provide technical assistance to anyone outside the USA or Canada in getting crypto working.
On the flip side, if you're using SSH, about the only practical way* for anyone to know if you're doing anything illegal is to search you out for TEMPEST emissions while you're doing it. <tongue-in-cheek>Hence the concept "It's only illegal if you get caught":-)</t-i-c>
*: This statement is based on the security of the crypto algorithms used in SSH.
Slashdot Mirror
Prudential uses it (partly for its logging facilities, partly for its ACLs, partly because they know that they can control what information is shown to/used/dealt with/modified by any part of their business).
Philips uses it for internal workflow and business intelligence.
Certifying Authority keys are assets, and thus capable of being transferred. The original name might be out of business, but the keys still exist.
I don't know if there's an ongoing audit requirement in that case, though.
There's a middle ground between "entity" and "communications." Yes, it is very difficult to verify that a certificate is being issued to the entity "Bank of America," but it should not be hard to verify that you're issuing a certificate to the domain name www.bankofamerica.com. And the latter is all you need to protect against MITM.
No, it's not. Mozilla knows of at least one instance where a user on a public wifi network had communications with a TLS-secured site MITM'd, and she allowed it by creating a security exception for an unknown CA that issued a certificate to CN=*.
Comodo's "authorityInformationAccess" only provides an OCSP responder URL, not a CRL. Apple's Keychain doesn't really handle OCSP by default (you have to go into Keychain Access, go to properties, go to the Certificates tab, and select OCSP: Best Attempt).
However, that's a "soft fail" mode, and if you block the OCSP responder host, it'll still allow it both in Firefox and Safari.
Mozilla and MS have made it as difficult as possible to inspect the certificate. Safari (and Apple's Keychain Manager) make it easier, but it's still a lot of information to try to digest.
I wish you'd put your two cents in on the dev-tech-crypto@mozilla.org mailing list.
Right now, they're avoiding removing the trust bits because that would essentially mean 3 months of not being able to authenticate Comodo certificates. They claim that it's because they don't want to inconvenience the end-users, but I tend to think that they're doing it because they've been paid not to.
SSL (now TLS) does allow certificate-less operation, and has since SSLv2. In that case, the key agreement is done via ephemeral Diffie-Hellman (DH without any static/attested key).
Why do you think Microsoft stopped trusting external CAs for its updates in Vista? It runs its own in-house CA at this point, and that's the only CA that can issue certificates that can sign updates for Windows.
Student tech service:
1) Provide a means and place for people to apply what they learn in class (simple webspaces, simple CGI on Apache) /done/.
2) Provide a means and place for people to learn about things they won't learn in class (WebDAV and deployment of Flash and real-world security policies)
3) Try to contact Microsoft and IBM to see about getting free copies of their software to make available for your group (as well as quotes on exactly how much they would cost if they were sold to real-world businesses), and if you have an academic advisor get them to make the inquiry for you.
4) More than anything else, become a means for students (and possibly people in the community who need help) to get the things that they need to get done
Take on the challenge of finding local nonprofits that need websites, and then find students (or teams of students) who are willing to take on those needs. Better yet, see if you can provide a list of site requirements to a web development instructor, or get the various parts of the faculty to look to you for real-world projects for their students' portfolios. (A web developer, say, to code it; a graphic-arts-for-web major to do the imagery; a back-end database guy to get real-world understanding of what the various database metrics actually mean; a project manager, to make sure everything gets done...)
Perhaps you could even go so far as to get something offered through your organization an independent CS course number for independent work.
Realistically, you know you need to make your organization non-redundant. I'm inclined to agree with the "college DJ" thing (especially if your college doesn't have a radio station, it'd be possible to build a netcasting system that would at least be available to people on your college network); I also agree with the ipv6 bridging idea (if you need an ipv6 tunnel provider, you can always email ipv6 at research.earthlink.net -- that's where I get my home tunnel from).
You have resources. You realize that your resources are being duplicated. Now, your job is to figure out how to keep your resources relevant. (I wonder if you could get business credit for trying to overhaul this -- you're basically doing what a CEO needs to do when faced with an increasingly competitive marketplace and the need to reinvent the organization.)
Above all: Good luck!
I dunno if anyone's actually looked at this, but it's a lot worse than "requires physical access". For example...
1) Any program running on your system automatically can run AppleScript.
2) Any system configured to do load sharing via Xgrid can have commands injected that will do this sort of thing.
3) Anyone who can access the machine from remote can do it, including via VNC.
osascript -e 'tell app "ARDAgent" to run shell script "chmod -r ugo-rwx /System/Library/RemoteManagement/ARDAgent.app"'
but re-run it after doing any kind of "repair permissions" on the volume.
PGPFone was a wonderful idea. The protocol it used was messy as all hell. I talked with Phil about it in 1997; he said that it wasn't being maintained because it didn't lend itself to being extended to actually use participants' PGP keys (instead of just "I hear this voice" authentication), and that at that point all rights to it were owned by the company that had just purchased PGP Corporation.
If I'm correct, the copyright statement is the (Copyleft 2002 by [person doing the copyrighting], released under the GNU Public License v2 [or, at your option, any later version]) thing?
If I remember correctly, if you wish to claim copyright protection, you must include several things:
1) The word 'copyright' (the (C) or (c) notation does not work);
2) The year of the work's release or creation;
3) The person (natural or corporate) asserting copyright.
This can be followed by "All rights reserved", which means that you are granting no rights except the right to obtain the copy to the person who's obtaining the copy. Or, you can specify a license for it all.
However, if you modify a GPL'd piece of software, you only own the copyright to the pieces that you wrote yourself -- therefore, you must still maintain the copyright notice from the original author, or else you're committing plagiarism (removing a signature and rereleasing == claiming that you wrote it).
Yes, you must retain the LICENSE (or LICENSE.TXT) file -- but you also must preserve the original author's copyright statement. (Unless it says "copyright abandoned" or similar.)
Actually, this is what 'discovery' is for. As soon as a lawsuit is slapped on, the lawyers get to go through a process where -everything- to do with the company's practices (including, but not limited to: the source code repository as of the date the lawsuit happened, as well as up to the date of the trial; any internal memos; any internal emails; any emails on developers' personal machines at home; any projected revenue statements; -anything- that at all has to do with the case at hand) regarding what they're charged with violating must be handed over.
Any company that is shown, in open court, to -not- be using at the very least CVS and more likely one of the larger source code revision tools will suddenly become the laughingstock of whatever industry they're trying to market software to... because what happens when old versions have bugs found, and need fixes without upgrading to the newest, slowest version? It also opens them up to lawsuits from shareholders, for not taking reasonable precautions (not performing due diligence) to maintain and grow the value of the stock in the shareholders' hands. Therefore, most companies won't have a lack of a development tree for revision control.
Easy enough to do with only a small program... it's called an "Open Mailing List". :)
I thought one of the points of the DMCA was that reverse-engineering for the purpose of creating a compatible implementation was specifically a defense?
Regardless, the reason this got to court in the first place was because of the -violation of the license agreement- of the software player they found the unencrypted key from. The obvious rule would be, in this instance, that "you cannot be bound by any contract that you sign that would limit your legal protections". (Especially in California, where such is specifically prohibited by law.)
Any thoughts?
Banking systems were using international SONET rings to deal with the massive data-transfer requirements a LONG time before 1990. -Winged
Keystone, at http://www.stonekeep.com/, is a PHP and MySQL/PostgreSQL/Informix-based helpdesk system that I'm finding very helpful in my job. The configuration is a bit hairy, but everything after initial configuration can be done through the web interface. Very slick.
Very, very interesting question. Essentially, we've got a situation where two different precedents exist: 1) Corporations can claim that the volume of the data passing through their services is such that tracking and maintaining its proper existence would place undue hardship upon them. They get cited as 'common carriers' in this case. 2) Individuals are -always- responsible for what their software sends out, and the 'common carrier' rule doesn't apply. (side note: I'm not sure what happens if a virus sends out pornography, who's responsible for it.) Hypothetically, it might be a good idea for the Freenet project to register as a corporation (non-profit would be better), and then make server operators 'members' of the organization. This would indemnify individual operators from the actions of the software that is required for membership. But, I don't know what the effect on the project itself would be. -Winged
Unfortunately, this interview leaves a lot to be desired, mainly in the aspect of exactly what Tridgell is currently working on. :/
I first ran into MainSoft when I needed a UNIX version of Visual SourceSafe. It appeared to do what I needed it to do (access repositories stored on a UNIX box, shared via Samba, between Windows and UNIX), and so my company bought it.
So I get called by a sales director, and we get to talking about this. (This was in April of 1999, btw.) I tell him that I'd -really- like to get my hands on a version for Linux, since that's where we were doing most of our coding. His answer was rather surprising... (Not a direct quote, but as much as I remember.)
"We haven't put any significant resources into Linux because we haven't had the demand for it. We would end up losing money on the porting. SourceSafe uses our MainWin library, and that's not ported right now, because developers don't seem to want to target Linux. We are, however, taking note of the number of requests, and it's quickly approaching critical mass."
Yes, I know, it's Marketing speaking, and Engineering is always a few months behind. But still.
He also gave some rather interesting insights into SourceSafe. He said that they got the source for SourceSafe 5 from Microsoft, and they ended up having to fix a lot of bugs in it. They did send the fixes back to MS. Anyway, they'd been promised the source for SourceSafe 6 a long while before they actually got it -- two months. They recommitted the resources they were going to use to do the port a couple of weeks before they actually got the source... and by then it was too late.
MainSoft has been one of the nicer companies I've ever had the pleasure of doing business with, actually. I do hope they succeed. (And they don't even, unlike MS FrontPage's Apache extensions, require root privilege to run!)
-Winged
As I learned a couple of years ago: People do what they feel is -right-. If it appears to be evil, it's only because the action is somewhat short-sighted.
Classifications go like this:
Public
Confidential
Secret
Top Secret
Confidential is a type of 'okay, the public shouldn't know this, but it doesn't hurt anything if they do find it out'. Secret is where 'the public is NOT to know this'. Top Secret is where 'even those people we trust with a Secret clearance are not to know this'.
On top of this, Confidential -should- not be shown to anyone outside of the need-to-know group; Secret and Top Secret -cannot- be shown to anyone outside the need-to-know group.
(Sorry, I just applied for a position at Rand not too long ago, and their network has an unclassified portion and a Secret portion. Anyone else ever read the Rainbow books?)
However, this doesn't mean that it can't be done. <pulls well-thumbed copy of Applied Cryptography, 2nd Edition down from its shelf> Chapter 6 in this book has a bunch of 'Esoteric Protocols', including 'Secure Elections'. I'd wholeheartedly recommend anyone doing any research into this field to get this book.
In a nutshell, there are at least 6 (and sometimes more) different requirements for a protocol that can be used for secure voting. These are:
- Only authorized voters can vote.
- No one can vote more than once.
- No one can determine for whom anyone else voted.
- No one can duplicate anyone else's vote (meaning, they can't just say "okay, I'll just make it easy and vote the way Bob did over there").
- No one can change anyone else's vote without it being discovered (and invalidated).
- Every voter can make sure that his vote has been taken into account in the final tabulation.
Some schemes can also have another requirement:There are very simple voting protocols, and the book describes the reasons these protocols don't meet the aforementioned requirements. (Some of these fall prey to the 'clipper chip' paranoia... "ohmigod, the government (or 'my party', etc) can figure out that I didn't vote for them!!!". Since voting's supposed to be -completely- anonymous from the time you're in the booth to the time you're not... I see this as a valid concern.)
There's a lot of useful things to be found in this book, and again, I wholeheartedly recommend it. There's undoubtedly been more research done in the 4 years since it was published; however, I've not been keeping up on that portion of the literature.
References:
_Applied Cryptography_, 2nd Edition, by Bruce Schneier, ISBN 0-471-11709-9. pp. 125-134. http://www.counterpane.com
Some of the above was taken directly from the book. Since I don't know HTML well enough to be able to format this the way it's supposed to be formatted in that case, please don't complain about my lack of proper formatting.
Unfortunately, everyone who has PGP 6.0 or higher (including the International version) without buying the RSA add-on, and the 128-bit high-security package from Microsoft. Not to mention everyone who uses MSIE.
Specifically, PGP 6.0 and higher use CryptoAPI to provide backwards-compatibility with RSA-signed/encrypted PGP 2.x messages, allowing them to be decrypted and encrypted to. (Unfortunately, this screws the security model a little bit, because since it can only generate a Diffie-Hellmann keypair, the 2.x recipient can't verify the signature.)
When an API is invented, people start using it. Once people start using it, it's dangerous. Ergo, creating an API that has backdoors is dangerous. Period.
Microsoft, fight the NSA.
On the flip side, if you're using SSH, about the only practical way* for anyone to know if you're doing anything illegal is to search you out for TEMPEST emissions while you're doing it. <tongue-in-cheek>Hence the concept "It's only illegal if you get caught" :-)</t-i-c>
*: This statement is based on the security of the crypto algorithms used in SSH.