SSH v. SRP 299
A reader asks, "We've all heard of SSH. My question is whether SSH is really the best option, or the only option? Many security experts and cryptographers believe SSH users may be lulled into a false sense of security, because of some outstanding security issues. An open-source project based at Stanford purports to have solved these problems."
The Stanford group claims SRP to be safe against snooping and immune to reply attacks. SRP exchanges a session key in the process of authentication, provides mutual authentication to resist dictionary attacks, offers what is supposed to be perfect forward secrecy, and does not require the server host to keep any information secure. This comparison of these two technologies should provide food for thought. Can SRP replace SSH? Does it truly offer more security? Is it the better choice? In simple terms, what are *your* thoughts?
SSH has been banged on for years (Score:5)
This counts a lot in my book, even if SRP is better in some areas, how well is it going to stand up when it starts getting banged arround.
Noel
RootPrompt.org -- Nothing but Unix [rootprompt.org]
Does it offer session encryption too? (Score:1)
Can SRP shroud X connections? (Score:2)
ssh -r and -l (Score:4)
-L port:host:hostport
Specifies that the given port on the local (client)
host is to be forwarded to the given host and port
on the remote side. This works by allocating a
socket to listen to port on the local side, and
whenever a connection is made to this port, the
connection is forwarded over the secure channel,
and a connection is made to host:hostport from the
remote machine. Port forwardings can also be spec-
ified in the configuration file. Only root can
forward privileged ports.
-R port:host:hostport
Specifies that the given port on the remote
(server) host is to be forwarded to the given host
and port on the local side. This works by allocat-
ing a socket to listen to port on the remote side,
and whenever a connection is made to this port, the
connection is forwarded over the secure channel,
and a connection is made to host:hostport from the
local machine. Port forwardings can also be speci-
fied in the configuration file. Privileged ports
can be forwarded only when logging in as root on
the remote machine.
Add tuneling, and I think your points are easily addressed.
Re:Telnet is the only solution. (Score:2)
I would think that SSH is limiting in that manner if you wish to test some daemon or something in security than it would be good. Also each and every public type machine that I have ever used and all unix machines I have never used have never either made ssh avaible or it was not really practal. SSH is only useful if you regularly connect to remote unix machines that support it or you have multiple machines with shell access.
That is simply not an option for me.
Therefore, the question:
Do we want to sacrifice our liberty for the sake of security? Not Thomas Jefferson, nor do I
*partial sarcasm*
Well considering how probably most of the people on slashdot are most likely on the FBI's most wanted list or are agents of the Iranian government trying to export 128 bit RSA I would think that they like it.
*end partial sarcasm*
Telnet With S/Key (Score:4)
From what I understand, it's only vulnerable to TCP hijacking (most things are) and dictionary attacks (which can be easily detected or accounts can be configured to be "locked out" after X bad login attempts).
The best one of these is OPIE [inner.net] which can provide a one time pad for telnet, FTP and even su.
Better yet, OpenBSD comes with this feature built into the OS.
It can't happen to me! (Score:3)
What I CAN do is point out that the most dangerous security attitude is "It can't happen to me!" There is no substitute for watching the security web sites, making sure you have applied the latest security patches, and simply being aware of what is happening on your system.
ssh is a definite plus over telnet, and I use it routinely. It is now just as natural to me as using the telnet command was 10 years ago. I'll certainly keep an eye on any new ways of doing things, but it would take a little more than what I have seen so far to make a switch at this time
-----------------------------------------
Yeah there are some at tucows (Score:3)
Actually if you look at your local tucows mirror you can get ssh type telnet shells. I know of at least one I saw being used but forgot the name.
SSH issues? (Score:2)
Also, does anybody have a mirror, it like this site is getting slashdotted already.
Re:Telnet is the only solution. (Score:2)
I look at SSH and I wonder if the protocol is generic enough to encrypt any stream. If it is, then why not write a ENFS(Encrypted NFS) file system for the kernel? You could theoretically use SSH-like schemes to authenticate and encrypt.
SSH, what a misnomer. (Score:1)
There's been how many bounce attacks and remote security issues with it? I know they designed it to be encrypted, but how about following up on the 'Secure' part of the name! I ended up not running it BECAUSE of the security issues it caused!
--
Gonzo Granzeau
Data encryption (Score:2)
Re:telnet rulez (Score:3)
Security (Score:5)
Re:If only I could SSH (Score:1)
Re:If only I could SSH (Score:2)
Re:If only I could SSH --- You can (Score:5)
Re:If only I could SSH (Score:2)
Re:If only I could SSH (Score:1)
Re:Telnet is the only solution. (Score:1)
Re:If only I could SSH (Score:1)
$Id: readme.txt 1.13 1998/06/30 13:36:45 c.igaly Exp c.igaly $
SSH Windows Client, version 24-June-1998
PLEASE, READ THIS TEXT. I DO NOT WANT TO SPEND TIME REPEATING SAME THINGS ALL OVER AGAIN.
DISCLAIMER
--------------------
THIS PROGRAM IS FREE. IF YOU ARE NOT HAPPY WITH CONDITIONS OF ITS USE, PLEASE DO NOT USE IT.
Source: You can freely use this program. Source is not available and I am ignoring all e-maill messages with request for it. If you dislike such policy, please feel free not to use it.
This program is distributed AS IS, and as such the author shall not be held liable for any loss of data, down time, loss of revenue or any other direct or indirect damage or claims caused by this program.
This program is not supported and there is no warranty or claim of fitness or reliability. I am trying to fix obvious bugs or improve it from time to time but I have no plans to do this on regular basis.
Bugs: This version is not crashing my system. At least not more than compiler(s) I've used to make it
Crypto Library: This program is using Peter Gutmann's Cryptlib. You can download last version (2.0) from ftp://garbo.uwasa.fi/pc/security/cryptl20.zip. You can alse use older version but this one is not available on garbo.uwasa.fi. Try to look at http://www.doc.ic.ac.uk/~ci2/ssh for alternative location. Beta version 2.1 can also be used. At this moment Blowfish is not working because implementations in SSH and Cryptlib are not compatible. Remember that cryptlib 2.0 is using ODBC so you must have it installed. If you do not want to do that, use cryptlib 1.1 (16- and 32-bit versions) or 2.1 beta version (32-bit version).
===============================================
Cedomir Igaly e-mail: c.igaly@doc.ic.ac.uk
Department of Computing
Imperial College of Science, Technology and Medicine
180 Queen's Gate London SW7 2BZ
United Kingdom
===============================================
pub 1024/DA5CB241 1994/12/19 Cedomir Igaly
Key fingerprint = 73 F2 6D 64 75 13 FE F2 D8 12 10 D4 9C C2 F4 3D
Cedomir Igaly
===============================================
Re:telnet rulez (Score:2)
Maybe there's nothing that you care about on the machine. I had a thought I don't know about you but perhaps if you security gets compromised and someone was doing one of these fabled attacks then perhaps you could just shut down the machine or turn it off in the first place?
[anonymous@coward
Password: ontheedge
[root@coward
Who transfers to the root partition as part of their normal access or for su'ing?
Next thing you know, you're taking part in a DDoS attack.
Assuming you edit the file
PKI and other issues (Score:4)
Works like this... you're host A connecting to host B but the packets go through host C. So unless host A and B have an alternate method to exchange keys, you're vulnerable to having host C replace the key with it's own, so in reality you're talking to host C and it's using a simple form of IP masquarading to make it look as if it's B or A...
So long as host C is the only route between the two (which is suprisingly easy to accomplish) - or through icmp and bgp manipulation makes that the case - you can ensure that host C has access to all the data over the wire even though those two hosts think they now have a trusted connection! Unless you can bypass host C via another path you won't even know it's happening.
Now, let me make this clear: there is no method for you to ensure data integrity over a public network like the internet. You must exchange keys over a secure medium before you can communicate securely over any network unless you can ensure that the entire network is under the same (trusted) administrative domain and have verified that it has not been tampered with (very, very difficult).
So in short: Yeah, SSH has problems. But this new program isn't going to make any leaps forward. You really need a PGP-style distributed key server system where you can verify the key's integrity through a trust network and/or via multiple independent routes / hosts. Otherwise, the alternative is a Kerberos-style system. Unfortunately THAT system has a single point of failure - if the key server is compromised your entire network is compromised. I'm not an expert though on Kerberos, so feedback is appreciated.
That is all,
Re:Telnet is the only solution. (Score:3)
For example, if you telnet into a server, su to root, do some root work, exit root account, read your email, exit the telnet session. If someone was sniffing your network they would have
1) you login and password
2) ROOTS! login and passowrd!!
3) the IP of the machine your telneted into
4) A rough idea of how you work, what "major" logs, info you check when you fist log on
5) that you girlfriend is pissed at you (via the email)
6) that your boss is pissed at you (via the email)
7) that pretty much anyone that emails you has some bitching to do about something (via the email)
8) how good of a typist you are.
Sure telnet is convent, but is insecure. If you do anytype of remote rooting(TM) you need SSH. I would highly suggest you use SSH for normal remote logs and ALWAYS use SSH when doing remote rooting(TM).
True story, I know a freind that used to go to college part time, and did Jr. level admin stuff for a local company. At school one day he was chilling at the computer lab after class, he got an email at his school's email account saying that their was problems with XYZ on the server at work and all hell was breaking loose. He quickly fired up Windows 95 Telnet, hoped over to the site in normal user mode, looked around and firgured out the problem. The problem needed root access, he shoved up the SU command without a thought, entered the password, fixed the problem, the bosses where happy.
The thing he didn't know was that there was a group of college security nerd playing around in the computer lab at the time, they where developing a Windows 95 ethernet sniffer. It was still beta, but it sure enough grab his password and also ROOT's password!!! They told him about it, and he promptly called an admin on site that changed root's password from the console, but if these security nerds in the computer lab where script kids or malice mother fuckers, who knows what would of happened!!
Sniffing is easy, try sniffit, a easy to use packet sniffer for Linux. When I was on help desk I used to sniff the admin computer and come up with all kinda of neat things. The thing I didn't want to find out though is that %90 of his day was involed in IRC chatting under the #lesbains channel with the nick Amy34Blonde (he was male).
Name one major hack based on an SSH weakness (Score:1)
Yes, SSH has weaknesses and the occasional buffer overflow, but the patches are made fairly quickly, and because of the high number of people using it, there is a high probability that other people will find a bug before it affects you.
Differences... (Score:4)
arbitrary TCP connections secured. It can even be used to support secure PPP
tunnels. SRP on the otherhand is less versatile. Only telnet and ftp seem to
be supported. Someone please correct me if I'm wrong, but as far as I know
SRP does not have any sort of connection forwarding like SSH does.
Another major difference is in licensing. SRP is under the GPL. No official
version of SSH is under a real open source licesense. SSH2 forbids any sort
of commercial use, even internally. SSH1 is slightly less restrictive in
that it allows for commercial use without paying them, but you can only use
it internally. These license restrictions are the reason SSH isn't found in
most linux distros.
However, there is an open source implementation of SSH being developed by
the OpenBSD people at http://www.openssh.org. It is ususably stable in its
current version.
The main thing SRP and SSH have in common is that they require no
infrastructure to be secure. In otherwords, you do not need any sort of key
distribution centers, or any other sort of software besides the daemon
itself and the client program to make everything work. Compare this to say,
Kerberos. Using kerberos, you can have secure connectivity to a machine,
however, there's a lot of additional infrastructure and complexity thrown
in, (such as KDC machines). You'll want to use Kerberos if you have a lot of
machines that will share a common user/password database. Kerberos will let
you log into one machine, say a kerberized workstation, and you'll be able
to securely log into any other machine (via telnet, rlogin, rsh, rcp, ssh,
ftp, pop3...) that's part of the same Kerberos realm without ever having to
type your password (assuming your client software supports Kerberos authentication).
SRP is arguably more secure than SSH, however SSH is a little more widely
implememnted and can be used for more things. If all you need is a secure
telnet and FTP, and the existing clients are suitable for you and you can
trust it (SRP is a litte newer), I'd give it a try.
Bwahahaha (Score:1)
"The Project's primary purpose is to improve network security from the ground up - by integrating secure password authentication into widely-used protocols instead of adding security as an afterthought."
Re:If only I could SSH (Score:1)
Audit it. (Score:1)
Apples and oranges (Score:4)
SSH on the other hand is a very useful application offering secure communications to another host. Keep in mind that SSH's password authentication happens after the encrypted channel has been set up. This means that the password can only be intercepted if the crypto fails.
SRP's security is based on similar cypro primitives as SSH's, so if the magic crypto hack we're all looking for gets found both will be useless.
Re:If only I could SSH (Score:1)
Re:Data encryption (Score:1)
3.SRP exchanges a session key in the process of authentication. This key can be used to encrypt the user's login session and protect it from both snooping and malicious active attack.
ssh does a similar thing - a session key is changed and can be used for encrypting the user's login session, etc.
Re:Yeah there are some at tucows (Score:1)
There's an SSH module available for Tera Term someplace. Incidentally, The Stanford guys use a modified version of Tera Term for their Windows SRP client. Last I checked, however, there were no SRP clients for MacOS, which IMO gives SSH a significant advantage with Mac clients like NiftyTelnet SSH out there.
I ran SRP daemons on my linux box for a while last year. It was relatively nice, supporting telnet and ftp, except it was meant as a replacement for your standard ftp and telnet daemons. This meant that things like dpkg would sometimes overwrite my SRP daemons when they decided it was time to upgrade ftpd.
Another disadvantage to SRP is that it creates yet another set of password files (tpasswd if I recall). If you installed SRP on a machine with existing user accounts, you had to reset the users' password for them to be able to use SRP. If you decide to disallow non-SRP connections, this can be a big problem.
Don't get me wrong, I liked SRP. I sniffed one of my sessions once and all that was displayed was garbage, which made me feel nice and secure. But I personally feel that SRP hasn't been around long enough, and isn't supported as widely as SSH.
Sourceforge? (Score:4)
Re:SSH windoze client? Yes! Use TeraTerm. 3.1/9x/N (Score:2)
your machine is on the net, MS can probably read your keystrokes anyway.
secureCRT form for download [vandyke.com]
zow [tucows.com] Which also provides for ssh
Re:If only I could SSH (Score:2)
The main reason I like it is because it's just one .exe file. I always find when I'm in need of ssh there is no ssh-client installed on the machine I'm working on...
PuTTY doesn't waste my time with fancy installshields: you download it and you start it. That's it.
I must admit most of the time I'm working on unix machines, PuTTY is just to fill the gap... :-)
http://www.chiark.greenend.o rg.uk/~sgtatham/putty.html [greenend.org.uk]
Re:telnet rulez (Score:2)
Re:Telnet is the only solution. (Score:2)
I am just wondering if PCAnywhere (and other related NT admining tools) have encryption features comparable to ssh and friends?
SSH - the only secure solution... for now (Score:2)
Re:Telnet With S/Key (Score:1)
With the recent relaxation of encryption regulations in France and the U.S., the time has clearly come for all distributions to include encryption options right out of the box.
Re:Data encryption (Score:2)
SSH (Score:2)
So if you run an ISP, or just a webserver, in a few years your 'lusers' will be able to put up their nifty HTML and links to their family and friends' websites without compromising your security ...
Although Win2k comes with IPSec, its not the most obvious of things to set up, so don't expect 'em to be using it right away! Hopefully a default configuration will come along in a few years and we will all be able to surf safely.
p.s. In the meantime, can anyone recommend some international software that I can install to secure my FTP connections? I don't live in America, so I am missing out on all the websites with "download my great secure software" with a .org extension in the URL, not mentioning where they are hosted, cos I don't want the FBI, NSA, or whatever you people have banging on my door one night! So tell me! p.s. I already use PuTTY.
Re:PKI and other issues (Score:2)
You seem to be confused (umber hulks are a problem in your area?
Think about it this way. You, Alice, communicate with some entity at the other end of the wire. This entity tells you that it is Bob. Well, for this statement to be meaningful the label "Bob" has to refer to some entity that Alice knows of.
Now, if Alice and Bob-that-she-knows-of have a shared secret, Alice can test that the entity-on-the-other-end-of-the-wire is really Bob-that-she-knows-of. There are standard crypto protocols for this. However, consider the situation that Alice and Bob have no shared secrets. All that Alice knows about Bob is publicly available info. In this case Alice cannot be sure that the entity-on-the-other-end-of-the-wire is Bob-that-she-knows-of and there is no way for her to be sure.
Again, this problem has nothing to do with "data integrity over a public network". It all revolves around existence of a secret (=key) shared between Alice and Bob.
And, by the way, if Alice has a trusted PKI key server with a trusted path to it, then she can authenticate Bob easily enough over a different, completely non-secure network. That's all standard PKI stuff, really.
Kaa
I allow telnet in, but only as bait to nab h4x0rz (Score:2)
Re:Yeah there are some at tucows (Score:3)
Comparing Apples to Oranges (Score:2)
Re:PKI and other issues (Score:2)
The initial connection is important-- you need to get the right server key the first time (and any time the server changes it). But in the usual case, you have an independent way of verifying that you're connected to the site you think you are in special circumstances.
Re:telnet rulez (Score:3)
If a single machine on a network is compromised, the entire network's security is greatly decreased. If someone cracks my machine, 600 other machines become hugely more vulnerable because the first thing any even vaguely competent script-kiddie is going to do is install a packet sniffer. As for turning machines off if they start being used for DoS attacks - great. I'm sure the remote site will be thrilled that it only took a few hours for you to wake up/get home/notice before pulling the plug. Security is not something that should be dealt with half-heartedly, and if you're not going to care about security then your machine should not be allowed anywhere near the internet.
Who transfers to the root partition as part of their normal access or for su'ing?
That's what su - does.
Assuming you edit the file
You mean block root access at certain times of day? But that would prevent me from doing remote administration at certain times of day, and still does nothing to prevent someone packet sniffing my root password when I do use it. From that point on, I've lost. You should never transmit your root password via telnet unless you trust all the other hosts on your network.
Re:PKI and other issues (Score:2)
certificate authority only breaks authentication in that domain.
This is a good source of information on Kerberos. [mit.edu]
Re:Telnet With S/Key (Score:2)
---
Re:PKI and other issues, Interlock protocol (Score:5)
The protocol works this way:
1) A sends B his public key
2) B sends A his public key
3) A encrypts using B's public key and sends half the message to B
4) B encrypts using A's public key and sends half the message to B
5) A sends the other half to B
6) B sends the other half to A
7) Both A and B put the two halves together and decrypt the message with their private keys
If someone is in the middle, he can change the public keys by its own keys, but then in points 3 and 4 he will not be able to pass the real message because it has not been transmitted yet; he will have to invent a completely new message and though the "conversation" will be completely different. This is not a perfect solution since, in fact, he will be able to intercept at least the first messages exchange, but his presence would be detected quickly.
As you pointed, the good solution is to use some kind of trusted third party authentication.
Re:Name one major hack based on an SSH weakness (Score:3)
Here's a buffer overflow [rootshell.com].
Here's a bounce attack [rootshell.com]
Here's another one [rootshell.com].
Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago.
And don't tell me that 'patches come out quickly' because the bounce attacks were not patched for several weeks, and I know, because I was hit with them. So it might sound like just hype, but there is proof out there.
And I forgot, just because URL's were not included, I have no clue, right? Happier?
--
Gonzo Granzeau
SRP plus CIPE (Score:2)
We've used telnet over the Internet for over two years as our initial ASP offering (we're readying our web-based application to replace it). That is, we're able to deliver our *nix based enterprise application over the Internet via telnet (as long as we have a maximmum latency of 500 ms, that is). These issues of securing login and packet data had to be addressed for us to convince our Fortune 500 customers to buy into our Internet-based solution.
Combining SRP, for password transmission, and CIPE [sites.inka.de] for complete packet encryption, we're able to provide a reliably secure telnet session.
If we didn't have SRP and CIPE, we'd be SOL.
P.S. At the project's inception in 1996 we could not cost-justify any solution that required a per-user license fee. This threw us into Open Source solutions (and the ability to hack at the source code has proven a marvellous benefit since then).
Re:PKI and other issues (Score:5)
This latter belief appears to stem from the very shortsighted supposition that if you have an unguessable (not in crack files) password and always send it encrypted you'll be OK.
There are so many ways to get a password its not true. Passwords, while a good start, are not the be-all and end all of authorisation.
The public key authentication mechanism of SSH actually makes things worse, because the key is (effectively) tied to one or more computers rather being tied to the individual, which is almost always the wrong approach. Most authentication systems are trying to authenticate people, not computers - the fact that the same people often use the same computers is merely convenient - convenient for the computer system not the user.
Worse still, the public key, being digital, is easily copied without the owner knowing. Sure, it's password protected, but that just brings us back to passwords again.
So, for authentication I much prefer physical card based systems - i.e. two factor systems. You know when you've lost your card, you can keep track of who has cards, and you can't replicate stealthily.
SecurID is nice because it integrates well with existing systems - no special card reading hardware needed. Other such systems exist, too.
Sure, we need the encryption as well, but simply sending ye olde unix password over an encrypted channel is no magic solution to safe authentication.
Re:Differences... (Score:2)
Re:SSH has been banged on for years (Score:5)
For those who don't know, SRP just verifies the identity of a user to a server and, optionally, the server to the user. However, the process of this verification also _securely_ produces a shared symmetric key at both ends of the connection which can then be used to encrypt the rest of the session using a cipher of choice. Encryption is optional, if only secure authentication is required.
It's time we stop letting the fact that there aren't well ironed implementations of the protocol prevent us from using it. The main problem with the existing implemenatations from Stanford is that they require too many changes to the system (su, login, passwd, and some others) all have to be replaced with SRP aware versions, and yet another password file has to be created (/etc/tpasswd). PAM can probably relieve some of these problems (there used to be an SRP PAM module--is it still around?), but most of the difficulty with SRP lies in integrating it with your system. If we worked on simplifying this a bit, it could potentially be a very good solution.
Re:Security (Score:2)
Re:USe OpenSSH (Score:2)
You don't have to -- SSH happens to be from Finland. <grin>
ObURL: http://www.ssh.com/about/company/ [ssh.com]
Cheers,
-j.
Re:Once again, name a major hack due to SSH flaws (Score:2)
Having my box compromised due to someone evading tcp wrappers, or talking unencrypted.
One way, my box is hacked. The other, someone *might* be able to snoop me, assuming they have some node between myself and my box.
--
Gonzo Granzeau
Re:Telnet is the only solution. (Score:2)
> have ever used and all unix machines
> I have never used have never either made ssh
> avaible or it was not really practal. SSH is
> only useful if you regularly connect to remote
> unix machines that support it or you have
> multiple machines with shell access.
Well yes of course... ssh is only useful when
connecting to a host that has sshd installed.
Personally, here at work, ALL of our machines
use ssh. Also, any machine that is mine to
administer as I see fit, doesn't even support
telnet...I turn it off.
I think anyone who runs a unix server should
install ssh, and encourage all users to use it.
In fact, wherever even remotely feasable...telnet
should be turned off.
ssh is too easy to use to not support. plaintext
passwords are too easy to sniff to allow.
(I should note that we recently had a user acount
compromised, which we believe was the result of
a password sniff when one of our users was out
of the country and telnet'd in internationally)
-Steve
Re:Telnet is the only solution. (Score:2)
-dan
Re:Once again, name a major hack due to SSH flaws (Score:2)
Someone breached my network because of ssh. How 'secure' is that? It should be a solution, not the problem.
unencrypted telnet? I'll admit it's not the safest thing in the world, but I don't have a false sense of security, and I havn't had someone break in since sshd was removed.
Of course, I'll point out that this was all ssh1, not ssh2.
--
Gonzo Granzeau
Re:PKI and other issues, Interlock protocol (Score:3)
The algorithm you're suggesting is mostly a precursor of the current PKIs (I haven't read its reference paper, and don't really have the time to find it, but I wouldn't be surprised to find that it dates back ~RSA publication times).
By definition, at it's worst, a man-in-the-middle attack cannot be blocked/prevented: if A has never met B, there is no way for A to be convinced that she is really talking to B and not to C. If B is in the same situation (having never met A) and is also really speaking with C then although their communication may get from one to the other, it will always be possible for C to see all of it (since C can simply pretend to each of them to be the other player and then decrypt/reencrypt the message).
For trust to be achieved perfectly you will always need an additional piece of information (or mean of identification) in which you can trust... PKI's are one of the possible solutions. In the case of the Rivest-Shamir you're describing both parties must have common knowledge of the message's content prior to starting the algorithm otherwise a middleman could switch messages for it's own. In essence the protocol becomes dependant on the messages's nature and the fact that both players must know it... Two complete strangers could not use it.
But then again, there can't exist a protocol for two complete strangers to identify themselves to one another...
Re:Encryption style (Score:2)
First, the code you posted below, apparently never outputs anything but:
f1 :
f2 :
not a good cypher
cancelled
way :
pfa 0.1 by Frank Joppe (C) Copyright 2000
Usage:
pfa
pfa
--x Hexadecimal input, use lowercase only!
--help This screen
help
from a look at the binary. I'm not quite silly enough to try to run it, but I'm sure someone here on a scratch box will.
Secondly... Define fast? Faster than, say, http://www.entropia.net/prime [entropia.net]? They're using a massive distributed effort to factor prime numbers, and it still takes a serious amount of time.
My PIII 600 takes a few weeks to look for factors of (2^8858987)-1 using Lucas-Lehmer's algorithm. If you've got something that can top this, I'm sure a lot of people would like to know....
People like The EFF [eff.org] especially, who is offering up to $250,000 for large prime numbers.
How about some benchmarks, or some documentation on how it works? Or why you're using geocities to distribute it?
- Kevin
Re:PKI and other issues (Score:2)
> authenticate people, not computers - the fact
> that the same people often use the same
> computers is merely convenient - convenient for
> the computer system not the user.
>
> Worse still, the public key, being digital, is
> easily copied without the owner knowing. Sure,
> it's password protected, but that just brings us
> back to passwords again.
I have to agree and disagree.
ssh IS a very good system. The public key system
it uses does work. However, it only works if
the user sets it up right. (of course it is
defeatable if someone can sit in the middle and
play with all packets...thats besides the point
and not always, or even usually feasable)
The security of the system is in the encryption
of the private key. The authentication is that
anyone with the private key, has to be me (is
assumed). So...if my key has a passphrase...only
me can ever open the private key and use it...
even though it is stored on multiple machines
(hopefully moved to them in a secure manner)
only I can unlock it on any of these machines.
Re:Telnet is the only solution. (Score:2)
Re:Encryption style (Score:2)
Value added for SRP? (Score:5)
From a purely technical point of view, SSH, when using public key cryptography, is as secure as SRP. In the following list, I don't claim that SRP doesn't do any of these things; I'm merely clarifying what SSH does do.
- SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.
- SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.
- Authentication is done either with public/private keys or with a server side authentication mechanism, such as PAM. In the second case, any passwords or other information is transmitted encrypted, and so is secure. In the first case, the password is never transmitted and there is no chance of the user's password on the server being compromised through SSH. The user's password is never used to encrypt a session.
- OpenSSH, OpenSSL, and LSH are all open source, non-commercial projects.
- SSH allows securing of arbitrary ports, and provides extensive port forwarding capabilities. Therefore, any service on a server running SSHD can be secured, as long as the client program can alter the port of the service it is requesting. As an example, to secure an IMAP connection, one would issue: ssh -L 1442:servername:143 servername and then connect with their email client to localhost:1442.
- Although most users of OpenSSH are unaware of the fact, OpenSSL, which is required for OpenSSH, provides a powerful tool for dealing with X.509 certificates. With OpenSSL, you can encrypt, generate hashes, generate certificates, generate certificate requests, and perform a large number of other security-related actions. OpenSSL documentation is extremely sparce, and due to the complexity of X.509, using OpenSSL tools can be difficult; this is probably the primary reason why most people are oblivious to OpenSSL capabilities.
- OpenSSL is the basis for a number of port wrapping tools, such as sslwrap. With these tools, you can provide secure sockets to services such as HTTP, IMAP, telnet, and POP. Many clients, such as Netscape, understand secure sockets, and several ports are defined as "well known ports" for these secure services. (EG: IMAP's secure port is 993, and Netscape Communicator knows and can take advantage of this).
- Using public keys with SSH simplifies accessing services, so that 'ssh' and 'scp' are as easy to use as 'rsh' and 'rcp'. This is slightly less secure on a shared client, because the private key is held in the client memory during a login session, and is subject to core dump attacks. If the client machine is not shared, this is not an issue.
- OpenSS[HL] doesn't require using RSA algorithms; in fact, you can choose from any number of non-commercial algorithms.
The SRP site claims that there are several "advantages" to using SRP, but never says what these advantages are in relation to. In particular, the SRP site does not claim that SRP is more secure than SSH. SRP is certainly more secure that vanilla telnet, but I see no advantage to using SRP over SSH. The obvious advantage to using SSH over SRP is that SSH is ubiquitous, and well tested.Please, if anyone knows any way in which SRP is superior to SSH, I'd like to know.
Re:Security (Score:2)
Re:Telnet is the only solution. (Score:3)
When you telnet to a specific port you are just connecting a socket to it and passing stdin to it and passing what comes out of it to stdout. If you had to write this from scratch it would be about 150 lines of C code (and many fewer lines of perl or Java code). You aren't "sacrificing telnet" to use ssh!
The rest of telnet is support for terminal emulation and some terminal capabilties negotiation at start up, all of which works only when talking to telnetd, and none of which comes into play when connecting to any other port (unless, of course, you're connecting to telnetd on another port).
A later poster complains that ssh is only useful for shell accounts. Absurd. You can do arbitrary port forwarding through ssh, turning ANY network service into an encrypted service. It is a VERY handy way to create a secure opening through a firewall:
Machine A is behind a firewall that forbids incoming connections.
Machine B is out on the internet.
You want to use a service on machine A from machine C (another machine out on the internet).
Machine A can make an outbound ssh connection to machine B and tell machine B to open port 3500 on B for listen and to "tunnel" it to port 80 on machine A.
Machine C can then type this URL into his browser:
http://[machine B's address]:3500/
This will connect to port 3500 on machine B (obviously), but less obvious is that machine B will forward all traffic encrypted over the SAME ssh socket Machine A has open to B. No one observing the traffic between A and B will know that machine C sent traffic to machine A, nor will they be able to tell that more than one "conversation" is taking place over the single link.
SSH is not sacrificing freedom, it is enabling freedom. No, I won't use SSH2 (which is a close commercial product), but I certainly will use SSH1 and OpenSSH.
SSH is a major tool for flexibility,
SSH for Teraterm: TTSSH (Score:3)
You're thinking of TTSSH [zip.com.au]. When I have to use a random Windows box and I need SSH, this is what I download and use.
-----
The real meaning of the GNU GPL:
Apples and Oranges (Score:4)
SRP does the first step of keeping the initial authentication secret. Since both sides then have a secret random number as a side effect of SRP, it would be possible to use a collision resistent one-way hash to "sign" future packets. However, as far as I can tell, no implimentation of SRP currently accomplish signing of future packets. The last point can't be addressed while still meeting SRP's goals of not using encryption. This becomes a problem when legacy authenitication methods are used withen the SRP authenticated session. For example, withen an SSH encrypted stream, the "su" application can be run without revealing the password in clear text and without the application needing to be altered. SRP on the other hand only can address this if your willing to replace the "su" application and all other authentication applications to be used withen the session (passwd, DBA tools, etc.) via SRP based ones. In some cases, such as with database tools, an SRP replacement may not be possible. Therefore, SRP has it's own political problem of: is all your authentication application vendors accepting enough of SRP to provide you with an SRP aware version of their application? You may find that depending on what country you live in, the politics of SRP acceptence is far worse problem then the politics behind encryption.
That all having been said, I am impressed by SRP and would like to see it submitted to the W3C for use in future revisions in the HTTP standard. There are several cases that I'm aware of that keeping the password private is important but the data isn't sensative enough to warrent the overhead of SSL.
Advantages to SRP (Score:2)
Security-wise, the authentication protocol has been well investigated, and as far as I know it's stood up fine so far - no serious weaknesses have been discovered.
On the other hand, the SSH v1 protocol as implemented by OpenSSH and all other SSH v1 implementations has an insertion attack which allows the insertion of data into the stream because of insecure integrity protection (it uses a weak checksum). The SSH2 protocol fixes the design flaws in SSH1 (as well as allowing other key exchange schemes than RSA) but OpenSSH doesn't speak it (since it's based on an old SSH 1.x distribution). Hopefully this will change in the near future.
As part of the SRP authentication handshake, a session key can be shared which allows the rest of the session to be encrypted. So SRP provides for authentication as well as secrecy, like SSH does.
SRP is just an algorithm - there's nothing preventing someone from creating a SSH-like app which authenticates using SRP, and then provides all of the port-forwarding features which SSH does. This would be quite useful, actually, and is something I'm hoping to do when I get around to bringing native SRP capability into FreeBSD.
The major downside to SRP is that the authentication is only as strong as your passphrase. But on the other hand, this is true as well in SSH if you can get a hold of someone's encrypted private key (if they carry it around with them on a floppy so they can log in from random hosts, for example). This can be mitigated by enforcing strong passphrase selection on the SRP server. An attacker sniffing the authentication exchange cannot obtain any data which is useful for determining the passphrase, even by a brute-force dictionary attack - you have to obtain access to the
The Stanford SRP distribution is distributed under a BSD-style license. This is good for most people (e.g. commercial users who want to add SRP support to their products, etc), but it may prohibit the code from being incorporated into a larger GPLed program (because of the GPL's "no other restrictions" clause and the BSDL's "must give acknowledgement" clause). Consult your lawyer..
On the whole, SRP is more practical to implement because it doesn't require per-user client-side configuration. In most ways it seems to be a superior solution which is just awaiting wider adoption.
Re:Differences... (Score:2)
I am baffled by this assertion. I just downloaded srp-1.5.1. The LICENSE file in the docs subdirectory explicitly states that the license is akin to X11. The license also states that srp is "free for both commercial and non-commercial use."
In this case since the authors want srp to become a standard, its X11 type license is appropriate.
here are the links (Score:2)
It's not complete, and it's not meant to be.
Maybe this will help make it more so: homepages for some of the software you discuss.
Anyone interested in the software mentioned above, or even just general UNIX security, would do good do take a gander at OpenBSD (http://www.openbsd.org) [openbsd.org]. It's based on 4.4 BSD, like most of the Freenixes, and is designed with security foremost in mind. Think of it as FreeBSD after reading "1984". ;-)
It comes with OpenSSH. And Kerberos.
Ooh, and also... stickers! Put them on your box, and maybe the MiBs that break into your house while you're at work won't even bother trying to crack yer system.
Remember: paranoia is good. Anyone with doubts regarding the truth of that statement should check out the Echelon links that have been appearing here lately.
Ciao.
I am the Lord.
two-party vs. three-party authentication (Score:2)
SSH and (IIRC) IPsec use two-party authentication. That means anyone can talk to anyone else, but as another article pointed out it also opens the door to "man-in-the-middle" attacks.
Kerberos, digital-certificates and some government sponsored systems use three-party authentication. This puts some limitations on your use, but these are generally reasonable restrictions if you think about it. (E.g., do you really want John Cracker to be able to remote mount your files?) Third-party authentication got a bad rep after some clumsy government posturing with the clipper chip, but it seems that a lot of people lost track of the many places where it's appropriate.
Re: Kerberos (Score:2)
OpenSSH is still an excellent choice, but not because it alone supports Kerberos.
Re:SSHD everywhere? (Score:2)
>clients on all the desktops that we use to
> connect to our unix servers?
If the desktops are unix boxen...then they
should get their asses in gear and install
openssh (IMHO)
however...for Windows boxes...licencing can be
expensive. Here we have a SecureCRT licence pool
and ar eletting students and faculty get copies...
I have no idea what its costing the
University though.
Hopefully someday telnet will fall into disuse and
we can stop supporting it.
A metacomment (Score:2)
They can be sorted Newest First, Oldest First, or Highest Scores first. There are different levels you can set before it spills into index mode. You can change the threshold from -1 to 5. You can have different thresholds for replies. And it goes on and on. Besides, posts accumulate quickly - even with the same settings, it may not be "the one above" if you wait too long before hitting "submit".
So please, if you're going to refer to a post, and it's not one you're replying to, it helps to give the post's ID. That makes things much easier to follow.
Thanks.
Re:SSH, what a misnomer. (Score:2)
Oh, joy!
Here's a buffer overflow.
Quote:
Here's a bounce attack Here's another one.
Two examples of the same thing, from August and September 1997 and version 1.2.17. You realize that skript kiddies prey upon those who don't keep their software up-to-date?
Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago...
You mean this CERT advisory [cert.org] dated 13 Dec 1999?
Quote:
I think the lessons are:
1. Keep your software up-to-date.
2. Don't believe for a moment you're completely protected.
3. Keep informed of the latest in security threats.
The only completely safe computer is one that is incapable of being turned on.
James
SRP+SSH Vulnerabilities (Score:2)
The biggest weakness with Strong Password Authentication protocols like SRP, Natz, and B-SPEKE is that they are vulnerable to a man-in-the-middle attack if the password is known before hand. Thus these systems are worthless for encrypting data to a public resource, like public/anon FTP or a web site.
My biggest issue with SSH is very similar, a man-in-the-middle attack can performed when the server is sending its certificate to the client for the first time.
So basically they both suck, and to this end I have been working on a solution that combines the strengths of both to significantly minimize the cases where a man-in-the-middle attack could be employed.
Oh, BTW, you people that are comparing SRP to SSH based on features don't know what you're talking about. It would be trivial to use SRP allong with SSH or TLS's transport protocols, just using SRP for the authentication/key generation...so quit yacking about SRP not having X-windows tunneling support and whatnot....screw features, its the security thats important.
If you are interested in this, please email me at justin@cyrus.net or continue this thread.
Re:two-party vs. three-party authentication (Score:2)
SSH and (IIRC) IPsec use two-party authentication. That means anyone can talk to anyone else, but as another article pointed out it also opens the door to "man-in-the-middle" attacks.
Both SSH and IPsec also include mechanisms for prevention of MITM attacks. SSH uses RSA host keys which can be pre-exchanged (OpenSSH [openssh.com] extends this to include PGP-style key fingerprints), IPsec can use a variety of methods including preshared symmetric or PK keys or certificates for various forms (OpenPGP, X509, DNSSEC).
Re:SSHD everywhere? (Score:2)
Putty [greenend.org.uk] (http://www.chiark.greenend.org.uk/~sgtatham/putt
Not perfect, but good.
--
Re:Encryption style (Score:2)
*I* can find primes fast! (Score:2)
Cheers,
Ben
PS Here is a moderately efficient algorithm in an unefficient language:
#!/usr/bin/perl -w
# primes - generate primes
# Written for the PPT initiative by Jonathan Feinberg.
# The algorithm was substantially modified by Benjamin Tilly.
# See docs for license.
use strict;
#use integer; # faster, but cuts the maxint down
$|++;
my @primes = (2, 3, 5, 7, 11); # None have been tested
my @next_primes = (); # Avoid redoing work
my $VERSION = '1.002';
END {
close STDOUT || die "$0: can't close stdout: $!\n";
$? = 1 if $? == 255; # from die
}
chomp(my $start = @ARGV ? $ARGV[0] : <STDIN>);
my $end = $ARGV[1] || 2**32 - 1;
for ($start, $end) {
s/^\s*\+?(\d{1,10}).*/$1/ || die "$0: $_: illegal numeric format\n";
$_ > 2**32 - 1 && die "$0: $_: Numerical result out of range\n";
}
primes ($start, $end);
exit 0;
sub primes {
my ($start, $end) = @_;
return if $end <= $start;
if ($start <= 2 and 2 < $end) {
print "2\n";
}
$start = 3 if $start == 1; # Don't report 1 as a prime
$end--; # Reindex
# Initialize the list of primes
&more_primes($primes[-1]+1, int(2 * sqrt($end)));
while (scalar @next_primes) {
push @primes, @next_primes;
# Careful, we need to ensure that
# we get a prime past sqrt($end)...
&more_primes($primes[-1]+1, int(2 * sqrt($end)));
}
my $from = $start-1;
my $to = $from;
until ($to == $end) {
$from = $to + 1;
$to = $from + 99999; # By default do 100,000
$to = $end if $end < $to; # Unless I can finish in one pass
&more_primes($from, $to);
print map {"$_\n"} @next_primes; # Print primes
}
}
sub more_primes {
# This adds to the list of primes until it reaches $max
# or the square of the largest current prime (assumed odd)
my $base = shift;
my $max = shift;
my $square = $primes[-1] * $primes[-1];
$max = $square if $square < $max; # Determine what to find primes to
$base++ unless $base % 2; # Make the base odd
$max-- unless $max %2; # Make the max odd
$max = ($max - $base)/2; # Make $max into a count of odds
return @next_primes = () if $max < 0; # Sanity check
my @more = map {0} 0..$max; # Initialize array of 0's for the
# odd numbers in our range
shift @primes; # Remove 2
foreach my $p (@primes) {
my $start;
if ($base < $p * $p) {
$start = ($p * $p - $base)/2; # Start at the square
if ($max < $start) { # Rest of primes don't matter!
last;
}
}
else { # Start at first odd it divides
$start = $base % $p; # Find remainder
$start = $p - $start if $start; # Distance to first thing it divides
$start += $p if $start %2; # Distance to first odd it divides
$start = $start/2; # Reindex for counting over odd!
}
for (my $i = $start; $i <= $max; $i += $p) {
$more[$i] = 1;
}
}
unshift @primes, 2; # Replace 2
# Read off list of primes
@next_primes = map {$_ + $_ + $base} grep {$more[$_] == 0} 0..$max;
}
__END__
=head1 NAME
B<primes> - generate primes
=head1 SYNOPSIS
B<primes> [I<start> [I<stop>]]
=head1 DESCRIPTION
The B<primes> utility prints primes in ascending order, one per line,
starting at or above I<start> and continuing until, but not including
I<stop>. The I<start> value must be at least 0 and not greater than
stop. The I<stop> value must not be greater than 4294967295. The
default value of I<stop> is 4294967295.
When the primes utility is invoked with no arguments, I<start> is read
from standard input. I<stop> is taken to be 4294967295. The I<start>
value may be preceded by a single C<+>. The I<start> value is
terminated by a non-digit character (such as a newline).
=head1 BUGS
B<primes> has no known bugs.
=head1 AUTHOR
The Perl implementation of I<factor> was written by Jonathan Feinberg,
I<jdf@pobox.com> and Benjamin Tilly, I<ben.tilly@alumni.dartmouth.org>.
=head1 COPYRIGHT and LICENSE
This program is copyright (c) Jonathan Feinberg and Benjamin Tilly (1999).
This program is free and open software. You may use, modify, distribute,
and sell this program (and any modified variants) in any way you wish,
provided you do not restrict others from doing the same.
Try a 20 digit number (Score:2)
If you cannot come within shouting range of that, your algorithm is not likely to be interesting. If it does then it would be interesting is to know how your algorithm scales to, say, 30 digit numbers...
Ben
Re:Telnet is the only solution. (Score:2)
--
Oops (Score:2)
Cheers,
Ben
SRP is the secure one - cryptographic reasons (Score:2)
1) negotiate an encrypted session with the other party
2) authenticate the other party
3) the client sends the password in the encrypted session.
Clearly, if you can spoof the server you can get the Holy Grail: the real, plaintext password. This is why SSH flashes up big warnings saying "THIS SERVER IS UNAUTHENTICATED: REALLY PROCEED?" when you log on to a server the client hasn't seen before. To which everyone just presses "yes", defeating the so-called security. You can also get the Holy Grail if you can subvert a server to which the target logs on.
Contrariwise, SRP offers real network password security. SRP was designed around the assumption that the normal situation for network security was that people went up to new, vanilla clients and used only their passwords to log on to servers the clients had never seen before, and any protocl that wasn't secure under these assumptions just wasn't secure. SRP does damn cunning public key manipulations to allow the password to be used to verify both the client *and the server*, while only storing a password verifier on the server. Eavesdropping real connections, spoofing clients, or spoofing servers will leave you no better off than when you started; you can't even launch a dictionary attack, in contrast to disastrous protocols like CHAP which don't work for the low-entropy passphrases used in the real world. You can mount a dictionary attack if you subvert the server (this is unavoidable), but that's still more work than just reading the plaintext-equivalent phrase from the password file as is the case with challenge-response protocols; even subverting the server doesn't help.
SRP (and its cousin, B-SPEKE) solved the real, difficult problems of network password security. Accept no substitutes.
I only wish Slashdot didn't prioritise being first over being right so much, so more people could see the good information...
--
Re:Value added for SRP? (Score:3)
SRP is more secure than SSH+regular passwords.
SRP is more convenient than SSH+RSA authentication.
SRP can be integrated as an authentication mechanism for SSH (and it has, check out LSH).
Re:Network Topologies and sniffers (Score:2)
Really nasty when you do this to the gateway.
Defeating this requires security mechanisms which are rarely deployed at the switch level.
See the dsniff toolkit for example code.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Key Theory (Score:2)
SRP essentially combines the concept of "Hashed Password" and "Secret Key" into one small, low entropy object: The stored password.
"Dictionary attack" difficulties aside, it's not hard to imagine an intruder running a pre-computation attack against a password file. *However*, the password file *can be* much more secure--crypt() is far less secure than SHA-1, though SHA-1 isn't drastically better than the MD5 passwords deployed on most Linux boxen.
It is moderately unclear through the documentation how the "public verifier" gets distributed; more emphasis should be placed on this. The public verifier, distributed via OOB mechanisms, is *the only* way to get around "first contact" problems. Now, the public verifier can be shared, extended, chained, and so on, but at some point there has to be a Out Of Band(OOB) contact.
Of course, the problem with chains is Entropy Erosion and Failure Amplification--your original entropy never increases, but your risk of compromise *does*.
Another brought up a good point--SSH ideally requires compromise of both a private key(what you have) *and* passphrase(what you know) to experience a critical failure; SRP only requires one. One nice thing is that SRP can mandate that a user have a passphrase; I don't believe SSH has a truly secure method(not client based) to make sure that they don't.
More later, if anyone's still alive in this thread. (Gotta go.)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Re:Once again, name a major hack due to SSH flaws (Score:2)
Re:Value added for SRP? (Score:2)
This can be thwarted with a man-in-the-middle attack when the known hosts file is created.
Here's one where there is some value-add to SRP. In this case, both create session keys which, if cracked, cannot be used to crack other sessions. However, if the private keys to an SSH connection are leaked, then _all_ sessions can be immediately cracked. With SRP, even if the secret (a password) is known to an attacker, he can't crack sessions. He would be able to successfully authenticate himself, however. One thing I've never been sure of is what's actually stored in an SSH private key file. Is it the key itself, or an encrypted form of the key, which is decrypted with your passphrase? If so, then SSH keys do have some protection in the event of a system compromise. SRP does not store passwords on the system in cleartext, just verifiers. If the verifier file is compromised, then an (expensive) dictionary attack on it is possible. This is the only known way to employ a dictionary attack against SRP.
One difference between SRP and SSH (which I would call an advantage, some may call a disadvantage) is that SRP requires only an SRP enabled server and client to operate. If you know your password, you will authenticate successfully. With SSH, this will work if you have password authentication enabled, so that the two hosts authenticate each other, negotiate a symmetric key, and encrypt the password. As mentioned above, if those servers' keys are ever compromised, your password will be revealed to the attacker. To make SSH more secure you need to create your own keys on every machine you use, and copy the public key to the machines you wish to access. If the hosts you wish to access don't allow password authentication, then you can only access them from the particular computers you've explicitly allowed access from. This can be very inconvenient, especially when you work with many computers. In this case, I have to say I prefer SRP. One password works from anywhere with perfect forward secrecy.
Re:ssh -r and -l (Score:2)
The -p flag specifies a port to connect to, however, it requires an sshd to be connected to it. There is no ssh equivalent for 'telnet host port'.
$ telnet ftp.xemacs.org ftp
Trying 207.96.122.8...
Connected to gwyn.tux.org(207.96.122.8).
Escape character is '^]'.
220 ProFTPD 1.2.0pre8 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]
$ ssh -p 21 ftp.xemacs.org
Bad remote protocol version identification: '220 ProFTPD 1.2.0pre8 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]
Re:PKI and other issues, Interlock protocol (Score:2)
This won't work for all man in the middle cases. Consider this:
1)A sends B is public key
C intercepts that key can changes it to his public key
3)B sends A his public key
4)C intercpets and changes
5)A sends C a message encrypted with C's public key.
6)C decrypts and recrypts with B`s public key
7) B sends half the message encrypted.
You get the idea
Remember for this to work A and B have to have no non-seceret knowledge of the other that C does not share, and C needs compete high speed access to the entire data stream. Of course if any step is accomplished where C cannot get it (snail mail? federal crime, but doable. Meeting face to face can be fixed too, with impersonators.)
In the end you have to take some risk. Then again, if A and B know so little about each other and are doing buisness that is sensitive enough to encrypt they probably don't trust each other at all anyway.
Re:PKI and other issues (Score:2)
> protected it that way IN ADDITION to a password.
Well hell, add a "me too" on that. However,
even that scheme has its problem. The main
problme with it is hardware overhead.
It means that every machine you might wish to log
in from will need special hardware to read your
private key (unless you plan to type it in every
time)
I think that for most applications, and most
people, the ssh solution is "good enough" (of
course ssh doesn't say you can't put your private
key on a smart card or something...I am sure that
if you had a smart card reader it would be
trivial to change ssh to use it)
Take my current setup. my desktop has the
private key, with a moderately strong passphrase
(its not exactly random chars, but its not
going to fall to a dictionary attack or any
simple permutations)
If I remember right, an 128 bit hash is made of
the passphrase and used to encrypt the private
key. With a strong passphrase that is nearly
impossible to break.
more importantly.. the system is secure enough
that it would be easier to compromise the
machine or take me into an ally and beat me up
and force me to give them the passphrase then it
is to defeat it other ways... smart cards fall
to those exact same "methods".
RSA License and RSAREF (Score:2)
Those who actually tried to stay within a quasi-legal standing in compiling SSH1 with RSAREF ended up with an insecure implementation. The thing to consider here is... did it buy them much? There is still some question whether using RSAREF actually allows one to avoid licensing issues. I wouldn't be suprised to find more installations of SSH1 today compiled by admins who got fed up with the whole situation.
As a side note, admins working for the US Government have no need to worry about RSA licenses. The US Gov't has an open license to RSA since Government money was used in developing RSA at MIT.
Completeness Theorem != Incompleteness Theorem (Score:2)
> See Godel's Incompleteness Theorem
Ah, these are two different results. Godel's Completeness Theorem says that any *first order* statement which is true can be proved. "First order statements" are, essentially, mathematical statements which only talk about certain things. Amongst other things, first order statements can't talk about "For all sets such that blah".
On the other hand, there are statements which do include things like "for all sets such that blah " - called second order statements. Godel's *Incompleteness* Theorem says that there are some second order statements which are true but cannot be proven.
My comment was that FLT fits into the first category, so an automated proof is (theoretically) possible. Of course, it would take ages to run!
FLT not undecideable (Score:2)