Jump to content



Photo

help with DES and AES

java

  • Please log in to reply
48 replies to this topic

#31 vetthe evn show

the evn show

    Removed

  • Joined: 10-June 02

Posted 22 November 2012 - 06:56

removed


#32 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 22 November 2012 - 15:42

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

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....

#33 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 22 November 2012 - 15:55

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...

#34 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 22 November 2012 - 16:32

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

#35 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 5
  • Joined: 25-March 04
  • Location: England, UK

Posted 22 November 2012 - 19:48

  • 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 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.

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).

#36 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 22 November 2012 - 23:14

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?

#37 Andre S.

Andre S.

    Asik

  • Tech Issues Solved: 12
  • Joined: 26-October 05

Posted 23 November 2012 - 01:26

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.

#38 vetthe evn show

the evn show

    Removed

  • Joined: 10-June 02

Posted 23 November 2012 - 01:28

Removed

#39 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 23 November 2012 - 03:46

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

#40 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 5
  • Joined: 25-March 04
  • Location: England, UK

Posted 23 November 2012 - 03:51

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.

#41 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 23 November 2012 - 03:52

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 :D 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

#42 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 23 November 2012 - 04:00

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);
  }
    }
}


#43 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 5
  • Joined: 25-March 04
  • Location: England, UK

Posted 23 November 2012 - 04:24

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.

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 :D 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.

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 :p I hope I misunderstood...

#44 OP Original Poster

Original Poster

    Systems Developer

  • Tech Issues Solved: 1
  • Joined: 15-July 08
  • Location: my room
  • OS: windows 7/8, Kali, ubuntu, OSx 10.9
  • Phone: Android

Posted 23 November 2012 - 04:43

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 :p 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

#45 vetthe evn show

the evn show

    Removed

  • Joined: 10-June 02

Posted 23 November 2012 - 07:41

removed.