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