Note that the following assumes that one favors security with identity,
not anonymity (-:
From the perspective of the average user (like my father, siblings, and
most of my coworkers and customers), obtaining a PGP key is just about
as complex as obtaining an x.509 certificate (CA- or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Looking at JEP-0116 again, I see that public keys are used to verify the
identity of the parties, but that the stanzas themselves are signed and
encrypted with session keys. So identity is asserted and preserved in
the initial negotiation, but not
On Tuesday 07 March 2006 09:13, Peter Saint-Andre wrote:
Looking at JEP-0116 again, I see that public keys are used to verify the
identity of the parties, but that the stanzas themselves are signed and
encrypted with session keys. So identity is asserted and preserved in
the initial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Karneges wrote:
On Tuesday 07 March 2006 09:13, Peter Saint-Andre wrote:
Looking at JEP-0116 again, I see that public keys are used to verify the
identity of the parties, but that the stanzas themselves are signed and
encrypted with session
On Tuesday 07 March 2006 14:12, Peter Saint-Andre wrote:
So the repudiability and perfect forward security aspects of OTR don't give
me much comfort in the real world.
Exactly.
Interesting of you to bring up forward secrecy here. I believe that's where
if your public key is compromised, your
El dom, 05-03-2006 a las 14:38 +0200, Norman Rasmussen escribió:
Have you read 'JEP-0116: Encrypted Sessions'
(http://www.jabber.org/jeps/jep-0116.html)
JEP-0027 is only a Historical JEP, so it's not a standards-track spec,
JEP-0116 is a standards-track spec.
True, the thing is that
El mar, 07-03-2006 a las 14:49 -0800, Justin Karneges escribió:
On Tuesday 07 March 2006 14:12, Peter Saint-Andre wrote:
So the repudiability and perfect forward security aspects of OTR don't give
me much comfort in the real world.
The thing is that in the real world the cryptography will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michal Vaner (Vorner) wrote:
In fact anyone wanting to implement encrypted communications in their
clients should be implementing JEP-0116, and _not_ JEP-0027 - is
backwards compatability with older clients a good enough reason to
implement
Peter Saint-Andre wrote:
Now, neither OpenPGP or S/MIME enable you to repudiate what you said,
and if people find that important then they would need to do
JEP-0116 (or something very much like it, such as Gaim's OTR plugin).
So in part the differences here come down to requirements and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trejkaz wrote:
Peter Saint-Andre wrote:
Now, neither OpenPGP or S/MIME enable you to repudiate what you said,
and if people find that important then they would need to do
JEP-0116 (or something very much like it, such as Gaim's OTR plugin).
So in
Thanks to all for the answer/suggestions... What i have think now is to
automatize the process of exchanging keys using OpenPGP key servers,
after all they are suppossed to be synchronized, aren't they? Also i
will develop something to create the OpenPGP keypair (just in case the
user has not used
On Sunday 05 March 2006 22:05, Juan Antonio Gómez Moriano wrote:
Finally and considering that i will use OpenPGP to handle the
encryption, should i use GnuPG? I have been looking at the BouncyCastle
cryptography extension (a set of librearies to perform cryptographic
functions), by using that
Have you read 'JEP-0116: Encrypted Sessions'
(http://www.jabber.org/jeps/jep-0116.html)
JEP-0027 is only a Historical JEP, so it's not a standards-track spec,
JEP-0116 is a standards-track spec.
On 3/5/06, Juan Antonio Gómez Moriano [EMAIL PROTECTED] wrote:
Thanks to all for the
On 05 Mar 2006, at 13:38, Norman Rasmussen wrote:
yea, I've considered adding a button to Psi to do this many times.
A solution which doesn't require a button would be to use PEP to
publish your key.
cheers,
Remko
On 3/5/06, Remko Troncon [EMAIL PROTECTED] wrote:
On 05 Mar 2006, at 13:38, Norman Rasmussen wrote:
yea, I've considered adding a button to Psi to do this many times.
A solution which doesn't require a button would be to use PEP to
publish your key.
No, as I said: as Michal pointed out any
On 05 Mar 2006, at 18:26, Norman Rasmussen wrote:
No, as I said: as Michal pointed out any exchange of pgp/gpg keys
in-band will be insecure. (e.g. using the same tcp connection). The
keyservers are the 'right' place to store and get this information.
Retrieving keys from a keyserver is
On 3/5/06, Remko Troncon [EMAIL PROTECTED] wrote:
On 05 Mar 2006, at 18:26, Norman Rasmussen wrote:
No, as I said: as Michal pointed out any exchange of pgp/gpg keys
in-band will be insecure. (e.g. using the same tcp connection). The
keyservers are the 'right' place to store and get this
Dne neděle 05 březen 2006 21:04 Norman Rasmussen napsal(a):
On 3/5/06, Remko Troncon [EMAIL PROTECTED] wrote:
On 05 Mar 2006, at 18:26, Norman Rasmussen wrote:
No, as I said: as Michal pointed out any exchange of pgp/gpg keys
in-band will be insecure. (e.g. using the same tcp connection).
On Monday 06 March 2006 07:04, Norman Rasmussen wrote:
Agreed, gpg/pgp keys are 'supposed' to be inheriently strong, and
therefore no automatic retrieval/exchange should even/ever be done,
ever.
People are getting confused here.
There is *nothing* wrong with automatically retrieving the PGP
The thing is : how do i know in which server is the key of the
person i am
chatting with??
You can't. You have to assume that the user uploads his key to a
'sensible' server, which synchronizes with other major keyservers. If
he didn't, there's no way of retrieving the other person's
On 04 Mar 2006, at 23:19, Michal Vaner (Vorner) wrote:
the point with PGP is that user checks and signs the key (if he
trusts it).
Therefore, key exchange can not happen automatically, since it
would break
one of the main idea of PGP, that user knows who he is encrypting to.
Key exchange
21 matches
Mail list logo
