48 replies to this topic

[the evn show]

Quote

A piece of information needs to be shared between the two users. If a malicious person were to observe this piece of information being exchanged, that's not a problem, however if they were able to perform a man in the middle attack, then this would be useless.

• DH key exchange is still hard. It's no easier to crack the exchange process than to attempt to crack the the key used to encode a message directly. I've got a video that explains the process in easy-to-follow terms that I use to teach my non-math major friends. I'll find the link and edit it in.
  
• You can use DH key exchange to establish a secure channel. Once you've established the channel you can verify the party your connecting to using any of the standard methods.

The solution you proposed has the advantage of making it easy to to exchange public keys but ultimately doesn't address the problem of verification. Alice still needs a way to ensure that any given public key belongs to Bob. If you introduce a third party you just ask bob or alice to trust that third party instead of trusting eachother. Our goal isn't (and can't be) to ensure that a particular person belongs to a particular key. We can only hope to ensure that the person we talk to today is the same as the person we talked to yesterday.

We can do that by taking advantage of the way private and public keys are related. Alice generates a hash of a message she wants to send to bob. Alice encrypts the hash with her private key. Alice sends the message and the encrypted hash to bob. Bob recieves the message generates a hash of it. Bob decrypts Alice's encrypted hash using Alice's public key which he has. Bob compares the hash he's generated with the one alice sent him.
If they match then bob knows he's talking to whoever claimed to be alice yesterday.
If they don't match then he knows that eve is interfering in some way.

Quote

To eliminate the possibility of a man in the middle attack, you'd have to exchange it some other way, or at least confirm it some other way, i.e. over the phone.

Bob has no way of knowing that the public key he has belongs to alice and there is no system of verification that can be done without involving trust somewhere in the chain. If we want to trust that we're talking to alice then we should let her pick the locations where we can find her public key. If we dictate one central location then it's possible eve can compromise that site. Alice would notice her public key doesn't match but would have no way to communicate that (in a way we could trust) to anybody (because eve controls the one trusted location for public keys). If alice can publish her key 50 places then it's much more difficult for eve. Eve would need to compromise all of those locations simultaneously. Breaking only one location means bob could spot eve's medling by comparing the key from 1 site to the others that alice has claimed to publish it. All keys should be the same.



EDIT a simple explanation of how Diffie-helman key exchange resists man in the middle attack.

[SPEhosting]

articuno1au, on 22 November 2012 - 02:41, said:

It's particularly amusing given you flamed off at someone and told them not to underestimate you

Also, I doubt this will end up having any relevance to your current work given how you've proceeded, but it's worth a read: http://en.wikipedia....an_key_exchange

It's a very cool idea and should help you with basic crypto things in the future.

Another "for extra reading" recommendation is "The Code Book" by Simon Singh. Very good place to start if you want a crash course in Cryptography

Good luck with your project >.<

in all fairness I did just copy and paste it without much effort xD but even still i should of noticed .... but I have made great steps today in my code i am currently exchanging public keys over the web .... which is a lil annoying actually .... I may post back cause im stuck ... the person B has got the public key ... but i am having issues getting it to be a BigInteger .... it does not seem to like parsing a string to a big int....

[SPEhosting]

saying that actually .... here is the bit of code im having issues with ......

while ((inputLine = in.readLine ()) != null)
	    {
		 if (sy == 1) {
		 Sm = inputLine;
		 System.out.println(Sm);
		
		
		 String[] parts = Sm.split("!e! ", 2);
		 String string1 = parts[0];
		 String string2 = parts[1];
		
		 String j = string1.replace("!m!", "");
		 m = new BigInteger(j);
		 e = new BigInteger(string2);
}

one String is received and it is split up, ann manipulated to form raw keys .... as you can see ... this now makes me feel a little bit better after my stupid mistake as if you could see all my work its rather fancy :3 long winded probably ....but fancy .... so yes any suggestions as to why it does not like turning them into bigints.... they are all numbers no letters or symbols...

[SPEhosting]

I fixed my own issue.... if anyone wants to know ... there was a space.... easy enough to miss ... thank god for self built error checks

[+theblazingangel]

the evn show, on 22 November 2012 - 06:56, said:

• DH key exchange is still hard. It's no easier to crack the exchange process than to attempt to crack the the key used to encode a message directly. I've got a video that explains the process in easy-to-follow terms that I use to teach my non-math major friends. I'll find the link and edit it in.
  
• You can use DH key exchange to establish a secure channel. Once you've established the channel you can verify the party your connecting to using any of the standard methods.

The video was indeed helpful, thanks for that.

I'm not certain if it came across clearly, but it wasn't the key exchange itself I was questioning though, I can see with the video how that's secure, it's the fact that an attacker sat between bob and alice could intercept the exchange, so they never talk directly to each other, but instead without knowing are talking through the attacker.

the evn show, on 22 November 2012 - 06:56, said:

The solution you proposed has the advantage of making it easy to to exchange public keys but ultimately doesn't address the problem of verification. Alice still needs a way to ensure that any given public key belongs to Bob. If you introduce a third party you just ask bob or alice to trust that third party instead of trusting eachother. Our goal isn't (and can't be) to ensure that a particular person belongs to a particular key. We can only hope to ensure that the person we talk to today is the same as the person we talked to yesterday.

We can do that by taking advantage of the way private and public keys are related. Alice generates a hash of a message she wants to send to bob. Alice encrypts the hash with her private key. Alice sends the message and the encrypted hash to bob. Bob recieves the message generates a hash of it. Bob decrypts Alice's encrypted hash using Alice's public key which he has. Bob compares the hash he's generated with the one alice sent him.
If they match then bob knows he's talking to whoever claimed to be alice yesterday.
If they don't match then he knows that eve is interfering in some way.

the evn show, on 22 November 2012 - 06:56, said:

Bob has no way of knowing that the public key he has belongs to alice and there is no system of verification that can be done without involving trust somewhere in the chain. If we want to trust that we're talking to alice then we should let her pick the locations where we can find her public key. If we dictate one central location then it's possible eve can compromise that site. Alice would notice her public key doesn't match but would have no way to communicate that (in a way we could trust) to anybody (because eve controls the one trusted location for public keys). If alice can publish her key 50 places then it's much more difficult for eve. Eve would need to compromise all of those locations simultaneously. Breaking only one location means bob could spot eve's medling by comparing the key from 1 site to the others that alice has claimed to publish it. All keys should be the same.

EDIT a simple explanation of how Diffie-helman key exchange resists man in the middle attack.

I agree with everything you've said, I believe we are on the same wavelength.

With the bit underlined, knowing that you're talking to the same person as last time is meaningless if both conversations are going through an attacker, you're just confirming that you're going through the very same attacker and nothing has changed. Ensuring that you're talking directly to the other person and not through an attacker is the key problem, which is what you're talking about more of in the last quoted bit above. (Just wanted to make this a little clearer for others, not you, I can tell that you get this).

[SPEhosting]

theblazingangel, on 22 November 2012 - 19:48, said:

The video was indeed helpful, thanks for that.

I'm not certain if it came across clearly, but it wasn't the key exchange itself I was questioning though, I can see with the video how that's secure, it's the fact that an attacker sat between bob and alice could intercept the exchange, so they never talk directly to each other, but instead without knowing are talking through the attacker.




I agree with everything you've said, I believe we are on the same wavelength.

With the bit underlined, knowing that you're talking to the same person as last time is meaningless if both conversations are going through an attacker, you're just confirming that you're going through the very same attacker and nothing has changed. Ensuring that you're talking directly to the other person and not through an attacker is the key problem, which is what you're talking about more of in the last quoted bit above. (Just wanted to make this a little clearer for others, not you, I can tell that you get this).

if the key problem is the middle man ... why encrypt at all ? isnt the point of encryption to screw over the middle man in the first place?

[+Asik]

SPEhosting, on 22 November 2012 - 23:14, said:

if the key problem is the middle man ... why encrypt at all ? isnt the point of encryption to screw over the middle man in the first place?

http://en.wikipedia....le_of_an_attack

That's why PKIs exist.

[the evn show]

SPEhosting, on 22 November 2012 - 23:14, said:

if the key problem is the middle man ... why encrypt at all ? isnt the point of encryption to screw over the middle man in the first place?

Alice and Bob want to write letters to each other without Eve finding out. Alice and Bob live in an apartment that eve manages.Consider the different ways communication that could happen:

• Best case scenario Bob and Eve are able to communicate without Eve listening at. In this case they don't need to use any encryption at all because eve has no way of listening in.
  
• Eve can listen to one party's incomming communication. Eve reads messages sent from Alice to Bob, but not Bob to Alice. In this case Eve is Bob's wife. Whenever Alice sends a message eve just opens the mail box and reads it. When bob writes to alice he immediately drops it in the box so Eve never gets a chance to see it. In this case Alice needs to encrypt her messages but bob does not. This is easy because Bob can simply send a message to alice saying "use this password to encrypt all of your messages before you send them to me." Eve can see Alices messages when they arrive but without the password she cannot read them. You can imagine the opposite situation if Eve were alice's wife instead.
  
• Eve can listen to messages sent between both parties. Here Eve is the nosey apartment manager - she has keys to everybody's mail box so when they recieve messages she can just open the box and peek inside. Bob cannot send Alice a password to use (or vice versa) because eve will just read it when it arrives at it's destination. DH Key exchange allows bob and alice to agree on a password without revealing it to eve.
  
• Eve can read messages sent and can send messages that appear to come from any party. In this case you're "basically screwed. Eve could pretend to be bob and send a message to alice to establish a password (using dh key exchange for example). She could then pretend to be alice and establish a password with bob. From then on bob and alice communicate "through eve". Bob writes letters to eve pretending to be alice. Eve decodes bobs message, reads it, then rencodes it using alice's password and drops it in the mail box. Repeat for messages going in the other direction too.

If the only possible method of communication is via mail and there is no way for alice to receive a message from bob that eve cannot manipulate then eve and bob cannot communicate securely by any classical means.

Suppose there's a method that bob can send alice a message that eve cannot change but she can read. Imagine bob can spraypaint his key on the wall of the building. Everyone can read it but they also know who wrote it. If Eve and Alice both know Bob's public key it is possible for alice and bob to communicate privately because the public key can only be used to encode a message, not to decode it. Once alice has bob's public key, she can send him her own key and from there on they're both communicating privately because having 2 public keys doesn't get eve any closer to decoding the messages.

The point that +theblazingangel and I were discussing is of verification: without at least 1 message you know came from the party you want to talk to, you'll never know for sure that you're talking to the person you think you are. Imagine you met somebody at a pub and they said "Hey my name is Evn, lets have a few drinks." In the morning, how would you kinow you were really drinking and chatting with me and not some impersonator? If you knew what I looked like then you could be reasonably sure you were meeting me but without a picture, or some secret hand shake you'd have no way to know for sure. If you went out every week for a year - maybe you'd never be able to be sure that you were becoming my friend and not the friend of somebody impersonating me. You could ask people at the bar if they recognized me (but how do you know the impersonator didn't hire actors). The only way out of the trap is if we had some way outside of our pub meetings to verify identity. Maybe Neowin is trustworthy and we know that impersonators can't read PMs: you could send me a message saying "wear a red shirt and green shoes" and if the impersonator showed up at the bar with a blue shirt then you'd know he wasn't me. Alternatively, you could tell some secret to the impersonator and then check to see that I received it via PM. If the impersonator controls neowin then you have no way to be sure you're really talking to me.

[SPEhosting]

the evn show, on 23 November 2012 - 01:28, said:

Alice and Bob want to write letters to each other without Eve finding out. Alice and Bob live in an apartment that eve manages.Consider the different ways communication that could happen:

i get your point now ... hmm interesting to consider .... static ips would help here ....maybe but obviously .....you would want to be able to initiate without any issues.... maybe a log in function ? like skype or msn ... would help but would allow less anomity ...but then you could just run through the TOR network

[+theblazingangel]

SPEhosting, on 22 November 2012 - 23:14, said:

if the key problem is the middle man ... why encrypt at all ? isnt the point of encryption to screw over the middle man in the first place?

Of course it is, I'm not sure that I follow...

With both public-private key cryptography and DH, an exchange needs to take place of a piece of information crucial to establishing a secure channel of communication. In public-private key cryptography, this is the exchange of each other's public keys, in DH, this is a few numbers. In both cases, if this is observed only, it doesn't matter, the channel will be secure, however if an attacker is sitting between the two of them and intercepts this exchange then we do not have a secure channel, although it may look like it from the perspective of the two users. It's secure between Alice and the attacker, and between Bob and the attacker, but the attacker is silently decrypting, re-encrypting, and re-transmitting every message.

What you need is a way of ensuring that this data has really reached its destination, and not been intercepted and switched with the attacker's own. This is the tricky part. The proper way to do this is for the two users to communicate in another way, to verify that what they have received is correct (or to have agreed on a shared secret at some point in the past), which could be done for example by talking over the phone (if you'll recognise their voice and you're sure an attacker will not have the capability to intercept that and pretend to be them), or by meeting in person.

This is obviously a hassle, but with public private key cryptography can be minimised. For example, Alice and Bob meet in person to exchange keys, and they sign each others keys. John is friends with Alice and meets in person to exchange and sign keys. John then befriends Bob and wishes to communicate securely with him. Since Alice has already signed Bob's key, and John already trusts Alice's key, John does not have to actually meet with Bob. All that's needed to trust a new key is that at least one signature on it is from a key that you already trust. (Note that the work of exchanging keys and signing do not have to actually be done during the meetup, the keys could be exchanged beforehand, and just the key's shorter "fingerprint" compared. The signing of each others keys could be done later and uploaded to a public key server, so John here can get a copy of Bob's public key with Alice's signature already attached).

I suggested that this verification might be a problem for your system, it depends on people knowing each other in real life, or rather knowing at least one of the other users in real life, and establishing a network of trust through signing of each other's public keys. I outlined another option that you could take, which is to allow the web server to act as a "legitimate" middle man. Every user has a copy of the server's public key, and so can securely transport a copy of their own public key to it, and the server can then securely transfer it to the other user. It would not be possible for an attacker to compromise either key exchange. This simplifies things for the users who no longer need to meet up and verify something, however the server itself is a big weak point. The admin of the web server has the power to intercept communications, the government may force the admin to do so on their behalf, or an attacker could potentially break into the server and compromise everything. Whether you choose do this is your decision to make, I just wanted to cover it as part of my analysis. For users who do know each other in real life and are willing to do a proper exchange, this option would be much worse for them, but for users who do not know each other, even through a chain of other users, and therefore cannot validate each other's keys, as long as they are establishing connection to the right user on the system, public keys can be exchanged securely (with the exception of the server itself, which they would have to accept a compromise on).

Evn suggested that our goal should not be to try and know that a particular person owns a particular public key, but simply that once you've got a public key, that all future communications are coming from that same key, which is easy. This is indeed easy, however as I said in my reply, if the original communication was intercepted by an attacker, then by verifying that it's the same key, all you're doing is verifying that the same attacker(s) is still watching and no other attackers have joined in.

Evn also talked about the difficulties in obtaining the correct public key without a proper "meet up" type verification, which needs to involve some level of trust. Trusting a single service to store your public key would be foolish, because the service could just swap it out with one they've generated themselves. Evn suggested that storing it in multiple places, comparing copies from multiple places, and allowing the owner of the key to dictate where you go to get them from is much better, and I agree. However, this is by no means perfect. Firstly a powerful entity, e.g. the government, could easily have the capability to compromise this, by intercepting every transfer of a key on to and down from the internet. Additionally, without meeting in person, or talking over the phone, if instead Alice tells Bob through some digital communication which location(s) to visit to get the key, there's no guarantee that communication itself isn't compromised, or perhaps the user types in the correct url (or clicks the correct link), but it's invisibly redirected to a certificate owned by an attacker such as the government. There is absolutely no possible way to be sure that the exchange hasn't been compromised without meeting the other user in person, and checking with them.

Evn has now taken this even further to talk about the issue of knowing whether a person you don't already know really is know they say they are if you meet in real life to do the key exchange. This is certainly an interesting topic, and obviously only applies to people you don't already know. Someone you do already know might of course be lying to you about their identify also, but knowing that would be besides the point, you simply want to talk to that individual securely, no matter their real secret identity. With someone you don't know, let's say one of us wishes to talk securely to another, and need to do a secure key exchange, if we met in person, how would we know if the person we meet is the right person? In such a case all you can really do at the end of the day is make a judgement call, based on the real life likely hood of their being imposter, etc.

What we need to do here is take a look at the people who might be using the system and how they know each other.

• If all users of the system already know each other, i.e. you're just building this for use by your group of friends, then the best solution will be to establish a chain of trust by signing each other's keys until everyone has at least one signature from someone else in the group.
  
• If you're involving users who do not know each other in real life but do know each other through some other means, verification could be done through those other means. For example with us, we could verify each other's keys through Neowin. We would have to each assess the likely hood of our exchanges being compromised (e.g. by Neowin, by our ISP, by our government), and just accept that it's not a 100% guarantee, but probably not likely.
  
• If you're dealing with people who have never met each other, one of them has simply discovered the other through a chat service and initiated a chat session, then there's absolutely no way to guarantee security. However the method of having the web server as a "legitimate" middle man has advantages in some ways here.

Another interesting aspect to think about in all of this that's not been mentioned yet, is what if an attacker compromised the client application itself. I.e. you publish the software on a website, a user goes to download it, but an attacker has hacked the server and replaced it, or intercepts the download and serves a hacked copy instead. You'd need to take that into consideration also. To solve this, you'd need to sign the application, and provide your developer key to users. As a user, ensuring that the developer key that you have is correct has the same problems as already discussed.

[SPEhosting]

Dr_Asik, on 23 November 2012 - 01:26, said:

http://en.wikipedia....le_of_an_attack

That's why PKIs exist.

you will be happy to know i got my chat program working (mostly ...) i just have to finish a few things then i have a public and private key set up will post it once im done, just incase anyone wants to see/improve ... if i get time will be done within a day .... if not a couple of days (its very limited in what it does but the security is there ) .... my program shares keys on connection, fresh everytime... no reusing of keys

[SPEhosting]

theblazingangel, on 23 November 2012 - 03:51, said:

Of course it is, I'm not sure that I follow...

With both public-private key cryptography and DH, an exchange needs to take place of a piece of information crucial to establishing a secure channel of communication. In public-private key cryptography, this is the exchange of each other's public keys, in DH, this is a few numbers. In both cases, if this is observed only, it doesn't matter, the channel will be secure, however if an attacker is sitting between the two of them and intercepts this exchange then we do not have a secure channel, although it may look like it from the perspective of the two users. It's secure between Alice and the attacker, and between Bob and the attacker, but the attacker is silently decrypting, re-encrypting, and re-transmitting every message.

What you need is a way of ensuring that this data has really reached its destination, and not been intercepted and switched with the attacker's own. This is the tricky part. The proper way to do this is for the two users to communicate in another way, to verify that what they have received is correct (or to have agreed on a shared secret at some point in the past), which could be done for example by talking over the phone (if you'll recognise their voice and you're sure an attacker will not have the capability to intercept that and pretend to be them), or by meeting in person.

This is obviously a hassle, but with public private key cryptography can be minimised. For example, Alice and Bob meet in person to exchange keys, and they sign each others keys. John is friends with Alice and meets in person to exchange and sign keys. John then befriends Bob and wishes to communicate securely with him. Since Alice has already signed Bob's key, and John already trusts Alice's key, John does not have to actually meet with Bob. All that's needed to trust a new key is that at least one signature on it is from a key that you already trust. (Note that the work of exchanging keys and signing do not have to actually be done during the meetup, the keys could be exchanged beforehand, and just the key's shorter "fingerprint" compared. The signing of each others keys could be done later and uploaded to a public key server, so John here can get a copy of Bob's public key with Alice's signature already attached).

I suggested that this verification might be a problem for your system, it depends on people knowing each other in real life, or rather knowing at least one of the other users in real life, and establishing a network of trust through signing of each other's public keys. I outlined another option that you could take, which is to allow the web server to act as a "legitimate" middle man. Every user has a copy of the server's public key, and so can securely transport a copy of their own public key to it, and the server can then securely transfer it to the other user. It would not be possible for an attacker to compromise either key exchange. This simplifies things for the users who no longer need to meet up and verify something, however the server itself is a big weak point. The admin of the web server has the power to intercept communications, the government may force the admin to do so on their behalf, or an attacker could potentially break into the server and compromise everything. Whether you choose do this is your decision to make, I just wanted to cover it as part of my analysis. For users who do know each other in real life and are willing to do a proper exchange, this option would be much worse for them, but for users who do not know each other, even through a chain of other users, and therefore cannot validate each other's keys, as long as they are establishing connection to the right user on the system, public keys can be exchanged securely (with the exception of the server itself, which they would have to accept a compromise on).

Evn suggested that our goal should not be to try and know that a particular person owns a particular public key, but simply that once you've got a public key, that all future communications are coming from that same key, which is easy. This is indeed easy, however as I said in my reply, if the original communication was intercepted by an attacker, then by verifying that it's the same key, all you're doing is verifying that the same attacker(s) is still watching and no other attackers have joined in.

Evn also talked about the difficulties in obtaining the correct public key without a proper "meet up" type verification, which needs to involve some level of trust. Trusting a single service to store your public key would be foolish, because the service could just swap it out with one they've generated themselves. Evn suggested that storing it in multiple places, comparing copies from multiple places, and allowing the owner of the key to dictate where you go to get them from is much better, and I agree. However, this is by no means perfect. Firstly a powerful entity, e.g. the government, could easily have the capability to compromise this, by intercepting every transfer of a key on to and down from the internet. Additionally, without meeting in person, or talking over the phone, if instead Alice tells Bob through some digital communication which location(s) to visit to get the key, there's no guarantee that communication itself isn't compromised, or perhaps the user types in the correct url (or clicks the correct link), but it's invisibly redirected to a certificate owned by an attacker such as the government. There is absolutely no possible way to be sure that the exchange hasn't been compromised without meeting the other user in person, and checking with them.

Evn has now taken this even further to talk about the issue of knowing whether a person you don't already know really is know they say they are if you meet in real life to do the key exchange. This is certainly an interesting topic, and obviously only applies to people you don't already know. Someone you do already know might of course be lying to you about their identify also, but knowing that would be besides the point, you simply want to talk to that individual securely, no matter their real secret identity. With someone you don't know, let's say one of us wishes to talk securely to another, and need to do a secure key exchange, if we met in person, how would we know if the person we meet is the right person? In such a case all you can really do at the end of the day is make a judgement call, based on the real life likely hood of their being imposter, etc.

What we need to do here is take a look at the people who might be using the system and how they know each other.

• If all users of the system already know each other, i.e. you're just building this for use by your group of friends, then the best solution will be to establish a chain of trust by signing each other's keys until everyone has at least one signature from someone else in the group.
  
• If you're involving users who do not know each other in real life but do know each other through some other means, verification could be done through those other means. For example with us, we could verify each other's keys through Neowin. We would have to each assess the likely hood of our exchanges being compromised (e.g. by Neowin, by our ISP, by our government), and just accept that it's not a 100% guarantee, but probably not likely.
  
• If you're dealing with people who have never met each other, one of them has simply discovered the other through a chat service and initiated a chat session, then there's absolutely no way to guarantee security. However the method of having the web server as a "legitimate" middle man has advantages in some ways here.

Another interesting aspect to think about in all of this that's not been mentioned yet, is what if an attacker compromised the client application itself. I.e. you publish the software on a website, a user goes to download it, but an attacker has hacked the server and replaced it, or intercepts the download and serves a hacked copy instead. You'd need to take that into consideration also. To solve this, you'd need to sign the application, and provide your developer key to users. As a user, ensuring that the developer key that you have is correct has the same problems as already discussed.

the simple way for a select group of friends is to simply ask them questions only they would know ... on the encrypted level once you confirm its them ... you know their key .... at the moment this is a private chat project .... it will become a massive anyone can use it system in the future .... but at the moment im keeping it as is (if i work to fast I might screwed over, as Il be using the advanced thing in a research paper I have to start next year)

the host lol ... I am not quite done I still have to finish decryption .... but i have made a mistake in the clientside .....and i have no idea what i have done...

import java.net.*;
import java.security.InvalidKeyException;
import java.security.Key;
import java.security.KeyFactory;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.NoSuchAlgorithmException;
import java.security.PublicKey;
import java.security.spec.InvalidKeySpecException;
import java.security.spec.RSAPublicKeySpec;		
import java.awt.event.*;
import java.math.*;
import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
import javax.crypto.IllegalBlockSizeException;
import javax.crypto.NoSuchPaddingException;
import java.io.*;
public class SwingChatServer extends SwingChatGUI
{
/**
  *
  */
private static final long serialVersionUID = 1L;
PrintWriter out;
BufferedReader in;
BufferedReader stdin;
	 public ButtonHandler bH;
	 static int sy = 0;
	 private BigInteger e;
	 private BigInteger m;
	 private String Se;
	 private String Sm;
private Key jim;
PublicKey pubKey;
String inputLine, outputLine;
public ButtonHandler bHandler = new ButtonHandler();
   
public SwingChatServer (String title)
{
  super (title);
  bHandler = new ButtonHandler ();
  sendButton.addActionListener (bHandler);
 
  bH = new ButtonHandler();
  synco.addActionListener( bH );
}
private class ButtonHandler implements ActionListener
{
  public void actionPerformed (ActionEvent event)
  {
   if (event.getSource()==sendButton) {
		
   
		 if (sy == 1) {
		  //EtS = txArea.getText ();
		  try {
	  kpairs();
	 } catch (InvalidKeyException e) {
	  // TODO Auto-generated catch block
	  e.printStackTrace();
	 } catch (NoSuchAlgorithmException e) {
	  // TODO Auto-generated catch block
	  e.printStackTrace();
	 } catch (InvalidKeySpecException e) {
	  // TODO Auto-generated catch block
	  e.printStackTrace();
	 } catch (NoSuchPaddingException e) {
	  // TODO Auto-generated catch block
	  e.printStackTrace();
	 } catch (IllegalBlockSizeException e) {
	  // TODO Auto-generated catch block
	  e.printStackTrace();
	 } catch (BadPaddingException e) {
	  // TODO Auto-generated catch block
	  e.printStackTrace();
	 }
		 
		 } else {
		 
		 
		 }
	    }
	    if (event.getSource()==synco){
		
		 String syn = "Accepted press 'sync' again";
		 String outputLine = syn;
		 out.println (outputLine);
		 sy = 1;
		
		
	    }
	 }
}
   
public void run () throws IOException, InvalidKeyException, NoSuchAlgorithmException, InvalidKeySpecException, NoSuchPaddingException, IllegalBlockSizeException, BadPaddingException
{
  ServerSocket serverSocket = null;
	  
  try
	    {
		 serverSocket = new ServerSocket (1978);
	    }
	    catch (IOException e)
	    {
		 System.err.println ("Could not listen on port: 4444.");
		 System.exit (1);
	    }
	    Socket clientSocket = null;
	    try
	    {
		 clientSocket = serverSocket.accept ();
	    }
	    catch (IOException e)
	    {
		 System.err.println ("Accept failed.");
		 System.exit(1);
	    }
	 out = new PrintWriter (clientSocket.getOutputStream (), true);
	 in = new BufferedReader (new InputStreamReader (clientSocket.getInputStream ()));
	 //stdin = new BufferedReader (new InputStreamReader (System.in));
	    out.println ("Welcome to the Chat Server\n");
	    while ((inputLine = in.readLine ()) != null)
	    {
		 if (sy == 1) {
		 Sm = inputLine;
		 System.out.println(Sm);
		
		
		 String[] parts = Sm.split("!e! ", 2);
		 String string1 = parts[0];
		 String string2 = parts[1];
 
		
		 String j = string1.replace("!m! ", "");

  System.out.println("_______---------------______________----------->" + j);
		 m = new BigInteger(j);
		 e = new BigInteger(string2);
		
		 //e = new BigInteger(Se);
		 if (Sm != null) {
		
		
		
		
		  sy = 2;
		  kpairs();
		 }
		 }
		 System.out.println ("Server < " + inputLine);
		 rxArea.setText (inputLine);
	    }
 
	    out.close();
	    in.close();
	    clientSocket.close();
	    serverSocket.close();
    }
public void kpairs() throws NoSuchAlgorithmException, InvalidKeySpecException, NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException, BadPaddingException
{
 
  if (sy == 0) {
 
  try {
   KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
   kpg.initialize(1024);
   KeyPair kp = kpg.genKeyPair();
   Key publicKey = kp.getPublic();
   Key privateKey = kp.getPrivate();
   jim = privateKey;
   out.println("public key: " + publicKey);
   }
   catch (NoSuchAlgorithmException e) {
  
   }
 
  }
 
  if (sy == 1) {
  
	  RSAPublicKeySpec keySpec = new RSAPublicKeySpec(m, e);
	  KeyFactory fact = KeyFactory.getInstance("RSA");
	  pubKey = fact.generatePublic(keySpec);
	 
   outputLine = txArea.getText ();
		  System.out.println ("Client > " + outputLine);
	 
	 byte[] src = outputLine.getBytes();
	 Cipher cipher = Cipher.getInstance("RSA");
	 cipher.init(Cipher.ENCRYPT_MODE, pubKey);
	 byte[] cipherData = cipher.doFinal(src);
	 out.println(new String(cipherData));
		 
	
  }
 
  }
public static void decrypt() {

}

    public static void main(String[] args)//throws IOException
    {
   SwingChatServer f = new SwingChatServer ("Chat Server Program");
 
  f.pack ();
  f.setVisible(true);
  try
  {
   try {
    f.run ();
   } catch (InvalidKeyException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (NoSuchAlgorithmException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (InvalidKeySpecException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (NoSuchPaddingException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (IllegalBlockSizeException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (BadPaddingException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   }
  }
  catch (IOException e)
  {
   System.err.println("Couldn't get I/O for the connection to: 194.81.104.118.");
   System.exit(1);
  }
    }
}

[+theblazingangel]

SPEhosting, on 23 November 2012 - 03:46, said:

i get your point now ... hmm interesting to consider .... static ips would help here ....maybe but obviously .....you would want to be able to initiate without any issues.... maybe a log in function ? like skype or msn ... would help but would allow less anomity ...but then you could just run through the TOR network

Absolutely none of what you've described is going to provide any sort of guarantee of establishing a secure exchange. Not if you want something that will be absolutely secure against absolutely any adversary, including your own government.

• Static IP. Many users such as myself have dynamic IP's, so this doesn't help us. Many people sit behind a NAT, and therefore could impersonate each other, etc
  
• Login. This only allows users to secure a particular alias and lock others out from using it. It in no way proves that the account belongs to the person it appears to belong to. Additionally a public key stored in the account could have been replaced by the admin of the service, etc.
  
• TOR. The idea with TOR is that your traffic disappears into a network through which it can't be traced back to you. It in itself is not a perfect solution and I personally do not trust it. While traffic is likely securely transmitted within TOR, the end nodes, where traffic enters and exits TOR can be monitored. The traffic coming out of the end node is not encrypted as it travels to the final destination. Who owns the nodes, the government could own many of them?! How is data transferred into TOR from the client securely? (seems to be a mixture of DH and TLS, well DH is something we've already discussed and cannot be secure on it's own. SSL/TLS is worthless in my opinion with the web's current HTTPS infrastructure, though it's use here might perhaps be okay and actually work securely if a self-signed certificate is being used and embedded in the TOR application, though you then need to trust the TOR developers and the copy of the application you've downloaded (as well as your operating system if we're really going to go that far). Ultimately though, TOR isn't going to actually help us one bit here.

SPEhosting, on 23 November 2012 - 03:52, said:

you will be happy to know i got my chat program working (mostly ...) i just have to finish a few things then i have a public and private key set up will post it once im done, just incase anyone wants to see/improve ... if i get time will be done within a day .... if not a couple of days (its very limited in what it does but the security is there ) .... my program shares keys on connection, fresh everytime... no reusing of keys

Re-read everything that's been written, what you're building is in no way going to be secure.

SPEhosting, on 23 November 2012 - 04:00, said:

the simple way for a select group of friends is to simply ask them questions only they would know ... on the encrypted level once you confirm its them ... you know their key

With a group of friends you already know, you'd meet them in person and verify each other's keys. If you're suggesting not doing this and instead establishing a connection to them, with what you hope to be a secure channel, and asking a question you hope that only they know the answer to in order to be sure you're connected to the right person... well I don;t know whether to go cry in despair, or come and smack you around the head with a heavy book I hope I misunderstood...

[SPEhosting]

theblazingangel, on 23 November 2012 - 04:24, said:

With a group of friends you already know, you'd meet them in person and verify each other's keys. If you're suggesting not doing this and instead establishing a connection to them, with what you hope to be a secure channel, and asking a question you hope that only they know the answer to in order to be sure you're connected to the right person... well I don;t know whether to go cry in despair, or come and smack you around the head with a heavy book I hope I misunderstood...

haha I know what you are saying! trust me I do ... im sure if you have read any of my posts im bad at explaining ...

I get the whole point of that key ... and noteting who you are connected to ... I personally think you are thinking to big scale for what im doing right now but I will have to do what you are suggesting .... which will probs involve mysql server (if I can ever get this damn driver working) ...

I could send a file to the other person containing the key and modulus but I dunno I guess im someone who is on the thinking line "no evidence, no crime" kind of thing while you are "know your friends and you will know your enemy" I dont think my ways are wrong (and im sure many would disagree) and I dont think yours are either .... I suppose its all opinion of what would be ideal ....

I dunno this requires some thought of what I want to achieve .... I know I want security, who I am talking to is not a concern for me ...because to understand the conversation you would have to be the person I want to talk to ....plus the person who is for now meant to be the other person to this program will be on the phone to me (skype) ... but as I said I also want to make this a big program ...when i change this to android I will probs make a file within the system...gah so much to consider at 5am

[the evn show]

Quote

I personally think you are thinking to big scale for what im doing right now

I agree here.

An Eve that can listen to everything is not out of the question. Any large government probably has that sort of sway and you can probably bet that even crooked cops and bored eemployees at major bones can probably pull it off. Your ISP can (so the bored employees there), your neighbors who hacked you WPA key, etc.
An Eve that can not only listen to everything but prevent Alice from talking to Bob through a channel she can't manipulate doesn't even exist in prisons. Considering an entity like this servers as an ideal to fight against. Classical systems will always require some side channel to establish the connection but once you've got that done you're off to the races. Quantum mechanical systems offer some security (observing the message can destroy it so that it can never be forwarded on) but nobody is doing quantum cryptography on any appreciable scale. It also tips a bunch of out assumptions upside down - factoring primes and the discrete log problem (the basis of cryptography systems we've been discussing) can be completed in polynomial time on quantum computers -- our current asymetic encryption systems just don't hold up. Interestingly: symetric systems do resist quantum attacks but don't fair well in classical systems because of the requirement of communicating the shared secret. So long as you hold to the requirement that Eve can manipulate anything you'll never be able to have a classical communication system between Alice and Bob that you can trust.

Quote

I know I want security, who I am talking to is not a concern for me ...because to understand the conversation you would have to be the person I want to talk to

The question we're trying to get you to consider is how you know you have a secure connection between you and the person you're speaking to.

You <-> Me (read, re-encrypt, resend) <-> target
You <-> Target

If you want security you need to ensure that you're talking in the second scenario. The only realistic way to do that is outside of the channel you're trying to secure. You can gamble that its unlikely to be compromised and that's probably fine for 99% of all communication. If I were up to something I really wanted to keep private (bank fraud, bomb plot, child prostitution, selling state secrets, etc) then I'd probably not want to take the chance.

You don't need to focus on that problem right away, but IMO you need to consider it eventually. Plus, that's the fun part anyway - it forces you into the cool areas in math that they just don't talk about anywhere else.



--

Before you make too much code, you should write up specs for your API or protocol.
What does establishing a connection look like (connect to server, post name/public key)
What features are there? (list connected users, disconnect, post message to specific user, post message to all users, get message for all users, get message for specific user)

The server will need a way of alerting clients to new content they'll be interested in (or the clients will have to periodically ask the server if there's new stuff). That's enough to get off the ground.

It probably wouldn't take more than half an hour to get a proof of concept server running node or sinatra up on heroku...might make a fun project