[Specs-cx] Encryption

[nara hideki]

Thank you for your clarification , David.

We are preparing "the draft for the draft" at
http://bitbucket.org/hdknr/openidcx/wiki/Structures about data
structure to be exchanged between parties.

Because public keys of requesters including the RP is delivered to the
OP in a CX Proposal JSON object contained in the OpenID Artifact
Binding request file,
the OP can asymmetrically encrypt a JSON containing privacy data of
the End User using JSON Encryption Envelope at the time when the OP
return it in the assertion to the RP.

I might have missed something important.

Regards.


2010/7/6 David García <david.garcia at tractis.com>:
> Hi Nara,
>
> I'll be a little bit more verbose :) .
>
> If all (public)keys are known you can perform an "encryption for recipients"
> so:
>
> (Pseudo code)
> encrypted_message = encrypt(message,symmetric_session_key)
> encrypted_keys = recipient_public_keys.collect{|key|
> encrypt_key(symmetric_session_key, key)}
> result = encrypted_message + encrypted_keys
>
> In the case you don't know recipient keys (any or all of them) you can use
> password based encryption to fill this gap.
> F.ex let's assume we're generating a content being delivered to n parties
> (still not known). The pseudocode will be the following:
>
> (More Pseudo code)
> encrypted_message = encrypt(message,symmetric_session_key)
> encrypted_keys = parties_randomly_generated_passwords.collect{|pass|
> pbe_encrypt_key(symmetric_session_key, pass)}
>
> result = encrypted_message + encrypted_keys
>
> And those keys will be delivered for some mechanisms (out-of-band, after a
> challenge has been passed...) to each party. Note that I do not apply pbe
> encryption over the content directly and I only propose to apply it to the
> session key, so we can still have this nice feature of having N independent
> keys (or passwords) decrypting the same content.
>
> Anyway it was just a random idea about the topic I wanted to comment about.
>
> If you consider those ideas could be helpful we can work on them if you want
> to.
>
> Best regards!
>
> Dave
>
> 2010/7/5 nara hideki <hdknr at ic-tact.co.jp>
>>
>> Hi, David,
>>
>> Let me know what you mentioned more precisely.
>> We're using JSON Encryption Envelop to exchange privacy data.
>> (Spec is here :
>> http://bitbucket.org/Nat/jsonenc/src/tip/draft-sakimura-jsonenc-00.txt
>> )
>> It encrypt shared key in public key encryption and the payload
>> of canonicalized JSON string is encrypted with that shared key.
>>
>> I think if those shared key is known, the payloads can be decrypted.
>> You might have talked about other security issues which I'm missing.
>>
>> Best regards.
>> ---
>> hdknr
>>
>>
>> 2010/6/28 David García <david.garcia at tractis.com>:
>> > Hi Nat,
>> >
>> > in those cases where public keys cannot be used, because parties are not
>> > known yet, maybe using PBE (password based encryption) with random
>> > generated
>> > pass could fit this need.
>> > Those passwords could be stored bound to the contract and delivered to
>> > the
>> > party after a challenge has been passed (f.ex auth process).
>> >
>> > Best regards
>> >
>> > Dave
>> >
>> > 2010/6/25 Nat Sakimura <sakimura at gmail.com>
>> >>
>> >> I had a talk with Hide yesterday.
>> >> We were talking on how to preserve the privacy of the end user among
>> >> bunch of services.
>> >>
>> >> The agreement we had was that we should encrypt the portion of the
>> >> agreement specific to each server with different symmetric keys, then
>> >> encrypt the symmetric keys with respective server's public key and
>> >> OP's public key.
>> >>
>> >> We are still discussing over the cases where parties are not
>> >> determined at the time of the proposal and disclosing the parties to
>> >> other parties are privacy risk.
>> >> It is a bit challenging.
>> >>
>> >> --
>> >> Nat Sakimura (=nat)
>> >> http://www.sakimura.org/en/
>> >> http://twitter.com/_nat_en
>> >> _______________________________________________
>> >> Specs-cx mailing list
>> >> Specs-cx at lists.openid.net
>> >> http://lists.openid.net/mailman/listinfo/openid-specs-cx
>> >
>> >
>> >
>> > --
>> > David Garcia
>> > CTO
>> > Tractis - Online contracts you can enforce
>> > http://www.tractis.com
>> > --
>> > Email: david.garcia at tractis.com
>> > Skype: deiffbcn
>> > Blog: http://blog.negonation.com
>> > Linkedin: http://www.linkedin.com/in/davebcn
>> >
>> >
>> >
>> > _______________________________________________
>> > Specs-cx mailing list
>> > Specs-cx at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-cx
>> >
>> >
>
>
>
> --
> David Garcia
> CTO
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Email: david.garcia at tractis.com
> Skype: deiffbcn
> Blog: http://blog.negonation.com
> Linkedin: http://www.linkedin.com/in/davebcn
>
>
>