1. Looking for old file encode.e
- Posted by tonysteward Jun 16, 2013
- 1492 views
Gday guys, I'm looking for an old library written by Derek called encode.e It's no longer in the archive. I used it many years ago and cant find it in my backups.
2. Re: Looking for old file encode.e
- Posted by DerekParnell (admin) Jun 16, 2013
- 1467 views
Gday guys, I'm looking for an old library written by Derek called encode.e It's no longer in the archive. I used it many years ago and cant find it in my backups.
Is it this one ?
3. Re: Looking for old file encode.e
- Posted by useless_ Jun 17, 2013
- 1384 views
Gday guys, I'm looking for an old library written by Derek called encode.e It's no longer in the archive. I used it many years ago and cant find it in my backups.
Is it this one ?
Something i did not understand then, or now: assuming this might be used for scrambling an email access, the recipient would need the same code the sender used, and the clear password beforehand, to generate the encrypted password to compare to what was sent by the sender. Or, the encrypted password would need to be sent in the clear as the password to the host, the same way the unencrypted password could have been sent. Either way, if all the traffic that the sender has ever sent has been logged, the password, encrypted or not, was sent, and is therefor known. And possibly the configured encode.e that made the encrypted password.
Or am i missing something?
useless
4. Re: Looking for old file encode.e
- Posted by DerekParnell (admin) Jun 17, 2013
- 1346 views
Something i did not understand ..., the recipient would need the same code the sender used, and the clear password beforehand, to generate the encrypted password to compare to what was sent by the sender. ...
Or am i missing something?
No, you are not missing something. This does not use a public/private key mechanism. The keys, or access to the (next) keys, needs to be given via an entirely different mechanism. The better way of doing this is using some sort of one-time-pad that all legal parties to the data know about. It would be a security issue to keep this protected so this is not expected to be used for long-term sensitive data. Another method is to use a public-private key system (e.g AES256) to generate the keys for encoding.
5. Re: Looking for old file encode.e
- Posted by tonysteward Jun 17, 2013
- 1346 views
Gday guys, I'm looking for an old library written by Derek called encode.e It's no longer in the archive. I used it many years ago and cant find it in my backups.
Is it this one ?
Yes thats it thank you.
6. Re: Looking for old file encode.e
- Posted by ghaberek (admin) Jun 17, 2013
- 1361 views
Something i did not understand ..., the recipient would need the same code the sender used, and the clear password beforehand, to generate the encrypted password to compare to what was sent by the sender. ...
Or am i missing something?
No, you are not missing something. This does not use a public/private key mechanism. The keys, or access to the (next) keys, needs to be given via an entirely different mechanism. The better way of doing this is using some sort of one-time-pad that all legal parties to the data know about. It would be a security issue to keep this protected so this is not expected to be used for long-term sensitive data. Another method is to use a public-private key system (e.g AES256) to generate the keys for encoding.
You could also use some sort of Diffie-Hellman key exchange to produce a shared secret between two parties. This is useful if you're sending encrypted content on-the-wire as part of your own protocol.
-Greg
7. Re: Looking for old file encode.e
- Posted by useless_ Jun 17, 2013
- 1288 views
Something i did not understand ..., the recipient would need the same code the sender used, and the clear password beforehand, to generate the encrypted password to compare to what was sent by the sender. ...
Or am i missing something?
No, you are not missing something. This does not use a public/private key mechanism. The keys, or access to the (next) keys, needs to be given via an entirely different mechanism. The better way of doing this is using some sort of one-time-pad that all legal parties to the data know about. It would be a security issue to keep this protected so this is not expected to be used for long-term sensitive data. Another method is to use a public-private key system (e.g AES256) to generate the keys for encoding.
They would also need the same encode.e, which contains the algorithm(s), magic number(s), pad value(s), etc(s). If a 3rd party did not have the encode.e, they could force it to be exchanged, and possibly captured intact, by corrupting either the sender's or the reciever's copy. A similar scene would be to swap out a wheel of the Enigma machine, it would still work, but now be incompatable with all other machines, at a minimum a whole new set of wheels would need to be sent.
useless
