Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation

[Tobias Heer <[e-mail]>]

Hi Dacheng,


Am 11.08.2009 um 06:21 schrieb Dacheng Zhang:

> HI,Tobi:
>
> You mentioned in your emails that your solution can provide a stronger
> binding between hierarchy information and HITs. I am a little  
> confused about
> this argument. Why do we need a stronger binding? Could your please  
> use an
> example to clarify in which condition the binging in current  
> solutions is
> not strong enough?

As I pointed out in my E-Mail to Tom, my main intention was to make  
you aware of the possibility to have a hierarchy-dependent HIT as  
described in draft-jiang-hiprg-hhit-arch-02.txt, not to point out any  
flaws in your design or in the current HIT design. If you don't see  
any application for this, feel free to discard the suggestion.

>
> In addition, there is something that I am not very sure in your  
> algorithm.
> If X is used to prevent guessing, the confidentiality of X must be
> guaranteed.
> That is, X must be kept privately.
X must be kept as secret as the hierarchical information. It is safe  
to reveal X to everyone who is intended to receive the hierarchical  
information.

> However, in your solution,
> communicating peers need to know X in order to verify the binding  
> between a
> HIT and its public key pair. Then how can two communicating peers  
> exchange X
> securely before they have achieved basic exchange?
>
This is where the Htag comes in. If you don't intend to disclose X and  
the hierarchy, the Htag is sufficient to verify the HIT / HI relation.  
Since the Htag is the result of H(Hierarchy, X), the hierarchical  
information cannot be guessed from the Htag. 	

BR,

Tobias

>
> ^_^
>
> BR
>
> Dacheng
>
> -----邮件原件-----
> 发件人: Tobias Heer [mailto:[e-mail]]
> 发送时间: 2009年8月11日 0:50
> 收件人: Henderson, Thomas R
> 抄送: [e-mail]; Xu Xiaohu; [e-mail]
> 主题: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00:
> Includinghieararchy in HIT generation
>
> Hi Tom,
>
> I was just picking up an idea that was described in another  
> hierarchical HIT
> draft (draft-jiang-hiprg-hhit-arch-02.txt). I did like the touch  
> that the
> "HIT" is determined by the hierarchy because it binds the hierarchy  
> to the
> HIT and it becomes more difficult to spoof the hierarchy information  
> for a
> given HIT because with a different hierarchy you end up with a  
> different
> HIT. Hence, the hierarchy information would be self certifying in  
> the sense
> that if I give a HIT to someone, the hierarchy would be bound to it  
> and it
> would stay like that unless I changed my HIT. I have not really  
> considered
> the practical benefits, I just wanted to tell the authors about the  
> other
> approach. Maybe the authors of draft-jiang-hiprg-hhit- arch-02.txt  
> can give
> some reasoning.
>
> Dacheng was worried that putting the hierarchy information into the  
> HITs
> would reveal the hierarchy (even in cases where this is not wanted).  
> Hence
> my suggestion to secure the hierarchy information with an additional  
> hash.
> However, since the number of hierarchies is probably too small to  
> make a
> full search through all hierarchies infeasible (one could just hash  
> each
> hierarchy information and see whether a given hash matches), I  
> introduced X,
> which is supposed to protect against this simple search. This was  
> only meant
> as a quick reply to Dacheng's privacy concerns.
>
> The proposed solution was not meant to replace the hierarchy  
> information in
> an additional parameter it was only intended to have a stronger  
> binding
> between hierarchy information and HIT. I already stated this in a  
> reply to
> Dancheng's e-mail on the list (28th of July,
> 17:29 GMT+3).
>
> You are perfectly right that the resulting hash is not a HIT in the  
> original
> sense, and yes you must supply the Htag to allow verification.  
> Hence, it
> must also be transmitted with the HI. And yes, it breaks backwards
> compatibility with hosts that don't know what to do with it.  
> However, since
> it seems that more hash functions will be introduced in the process of
> adding crypto agility to HIP, one could consider this as an  
> additional "hash
> function" or way of hashing.
>
> Don't get me wrong: I'm not saying we should do this. I just wanted  
> to make
> people aware of the way it is handled in the other draft.
>
> BR and greetings from Helsinki,
>
> Tobi
>
>
>
>
>
> Am 10.08.2009 um 19:12 schrieb Henderson, Thomas R:
>
>>
>>
>>> -----Original Message-----
>>> From: Tobias Heer [mailto:[e-mail]]
>>> Sent: Tuesday, July 28, 2009 6:02 AM
>>> To: [e-mail]; Xu Xiaohu
>>> Cc: [e-mail]
>>> Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00:
>>> Includinghieararchy in HIT generation
>>>
>>> Hi!
>>>
>>> I just wanted to clarify my comment in the HIPRG meeting on  
>>> including
>>> the hierarchy in the HIT creation process. I think it would be good
>>> to have the hierarchy information in the HIT creation process  
>>> because
>>> the hierarchy will be bound to the HIT itself.
>>>
>>> Below I briefly sketched a possible way of including it without
>>> revealing the hierarchy to all hosts.
>>>
>>> HIT generation could work like this:
>>>
>>> 1. Pick random secret X
>>>
>>> 2. H(Hierarchy, X) => HTag
>>>
>>> 3. H(PubKey, ..., HTag) => HIT (Orchid)
>>>
>>> --> Only use LTag if you do not want to reveal hierarchy.
>>> --> Use hierarchy and X if you want to reveal the hierarchy.
>>
>> Hi Tobias,
>>
>> I recently had a chance to listen to the audio archive of the meeting
>> and I'm reviewing the mail now.  Can you explain in more detail what
>> is the use case for what you are proposing?  I thought that the draft
>> was mainly concerned with having publicly revealed hierarchies so  
>> that
>> reverse lookups could exploit hierarchy.  In your proposal above, for
>> the observer who knows X, how does such observer retrieve hierarchy
>> bits, given the HIT, HTag, and X?
>>
>> Also, I am not sure you can claim that the result from your above  
>> is a
>> HIT, because according to RFC4843 and 5201, a HIT is formed without
>> these HTags.  In particular, the HIT would no longer be able to be
>> associated to the key, for an observer who does not know the magic
>> HTag to apply.
>>
>> Tom
>
>
>
>
> --  
>
> Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group  
> RWTH
> Aachen University, Germany
> tel: [phone]
> web: http://ds.cs.rwth-aachen.de/members/heer
>
>
>
>
>
>
>




--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer