quote:
Originally posted by Mattike
quote:
Originally posted by Jesus
the encrypted strings are a lot longer than the original ones, maybe you can make it so that if the encrypted string is too long it will be sent in parts so you don't have to bother about the length of the message?
Good idea, I think the encrypt function can pre-calculate the length of the encryption, so it can split and encrypt the separate strings.
* Mattike looks at phalanxii...
Yes, that is quite a good idea. I'll definitely put that in (although how will it work with F3 and F4?).
Just if you wanted to know, the length of the encryption is the block size times the original length plus one.
EDIT: Having trouble putting this one in... EDIT: Fixed!
@Cookie:
The user ID idea was probably not for security, but rather convenience. At the moment, the person that you send you're message to needs to know the key that you encrypted the message with, which I thought was a bit difficult in terms of practicality. (Note: This means that currently, you can send a message in a multi-contact conversation, as long as everyone else doesn't know the key.) But yes, I will probably need to reconsider the whole key concept, because as it stands, it is quite impractical (unless you don't mind telling your contact the key beforehand). However, like you said, using user IDs is also insecure.
Again, if anyone has any ideas as to how this should work, please suggest!
PS. Thanks for everybody's help so far!
Also, thanks for answering my last few questions. (I think I've got the contact list on the way, but I'm not sure whether I'll use it...)
EDIT: I just read up on PGP, and public-key encryption and private-key decryption seems a little out of my league...
EDIT #2: At the moment, I'm inclined to think that the key system will have to be left as is. There is no way for the script to generate a key for two users without communication or find the key within the message without there being a security threat from someone else doing the same.