Hierarchical Group Oriented encryption

**William Holroyd** · Jul 17 '05, 05:10 AM

Re: Hierarchical Group Oriented encryption

> I would like to use a hierarchical group oriented encryption.[color=blue]
> Is there something implemented or did you know something I could use?
>
> For explanaition.
>
> If you have a large building there are several keys available.
> Each person has a key to open his/her room. Probably this key is able to
> open rooms of the group of this person.
> Members of group A can't enter rooms from Group B.
> The bosses could enter the rooms of their group members but not rooms of
> other bosses.
> Another circle of security people could enter each room they have one
> general key.
>
> Is something similiar to this available to use for encryption/decryption?[/color]

Well, there is HIBE (Hierarchical Identity-Based Encryption) and FHIBE
(Forward-secure Hierarchical Identity-Based Encryption). Neither of which I
have seen used in PHP or anywhere else, but the concept is easy enough to
use to build on your own. You would have to build your own class to be able
to create them and decode/read them.

Here is a way to be able to build heirarchal based passwords...

Step 1) Remember back in grade school where you would take an 'encoded'
message and have to figure out what it actually said by using the alphabet
written out A-Z and then writing backwards Z-A under each letter you just
wrote (ex. A = Z, B = Y, C = X, etc...)? This is where you would get to make
your own. Using the A-Z & 0-9 characters, you have 36 letters/digits to
transpose the same way you did above. However, instead of making 1 = H, keep
the next level numerical so it's easier to compute. The number 36 divides 9
ways evenly (36/1=36, 36/2=18, 36/3=12, 36/4=9, 36/6=6, 36/9=4, 36/12=3,
36/18=2, 36/36=1). Using something not near the edge of that calculation
such as 36/6=6, which we will use below, would be optimal (more secure).
This table of cross-swapped chacters is our Reference.

Step 2) For each level in your infrastucture (admins [5], superusers [4],
groups [3], moderators [2], users [1]), a user's password would equal a
specific value according to their asigned level. This is where you add
another level of decryption by dividing the password up into segments much
like a MAC or IP address. Each segment would be a different value and the
total of all segments would be the value equivilent to that user's level
(see numbers in [] above).

Example 1:
Original Password: A9F4B8E5C7D6D6I 1KZH2LSG3
Divided into Segments: A9F4-B8E5-C7D6-D6I1-KZH2-LSG3

Example 2:
Original Password: SRXMTQWNUPVO1I0 J2HZK3G4F
Divided into Segments: SRXM-TQWN-UPVO-1I0J-2HZK-3G4F

Now for simplicity's sake, each segment in Example 1 & 2 equals 14, giving
the total value 84. Each group of two characters starting from either side
equals 7 (Example 1: A9, F4, B8, etc... all equal 7). Both examples are
equivilent in level and about the middle of the amount of passwords
possible. Each segment can only be as high as 24 using our current
Reference, giving the total segment value of 144 as the admin/root level
value.

In Example 1, I alternated from the outside on one side of my Reference to
the other when finding the key. Example 2 was made from the same Reference,
however I started from the middle and worked my way out, but both passwords
have an IDENTICAL LEVEL VALUE.

Using my Reference, you will be able to see how I was able to come up with
these...

A, G, M, S, Y, 4 = 1
B, H, N, T, Z, 5 = 2
C, I, O, U, 0, 6 = 3
D, J, P, V, 1, 7 = 4
E, K, Q, W, 2, 8 = 5
F, L, R, X, 3, 9 = 6

Now if we use the same Reference as just above, but now only allowing each
segment to be a total of 13 (or even keeping one half of them at 14 and the
others at 13), then you've just created a password inferior in security
level to the ones in Example 1 & 2;

Step 3) In my creation of the passwords used from my Reference, I never
reused a letter. After each character I used from my Reference, I marked it
as used and picked from another from the equivilant valued row. Additional
security would be to generate the Reference randomly and pick randomly from
the Reference when building passwords. DO NOT get fancy by multipling each
neighboring segment.191,102 ,976 possibilities may sound good, but
mathematically, YOU WILL come up with matching valued passwords that don't
equal the same security level. If you were, some sort of control would have
to be used to ensure that this would not happen, but would be a pain to code
and simpler if not used at all.

You can always build off of this example to increase the amount of
possibilities or security, but this is not a patented design.

Of course this is not what most people use when implementing HIBE/FHIBE, but
allows you to be able to do the same thing.

William

**Reimar Bauer** · Jul 17 '05, 05:12 AM

Re: Hierarchical Group Oriented encryption

Dear William,

thanks for this detailed explanaition,

Reimar

William Holroyd wrote:
[color=blue][color=green]
>> I would like to use a hierarchical group oriented encryption.
>> Is there something implemented or did you know something I could use?
>>
>> For explanaition.
>>
>> If you have a large building there are several keys available.
>> Each person has a key to open his/her room. Probably this key is able to
>> open rooms of the group of this person.
>> Members of group A can't enter rooms from Group B.
>> The bosses could enter the rooms of their group members but not rooms of
>> other bosses.
>> Another circle of security people could enter each room they have one
>> general key.
>>
>> Is something similiar to this available to use for encryption/decryption?[/color]
>
> Well, there is HIBE (Hierarchical Identity-Based Encryption) and FHIBE
> (Forward-secure Hierarchical Identity-Based Encryption). Neither of which
> I have seen used in PHP or anywhere else, but the concept is easy enough
> to use to build on your own. You would have to build your own class to be
> able to create them and decode/read them.
>
> Here is a way to be able to build heirarchal based passwords...
>
> Step 1) Remember back in grade school where you would take an 'encoded'
> message and have to figure out what it actually said by using the alphabet
> written out A-Z and then writing backwards Z-A under each letter you just
> wrote (ex. A = Z, B = Y, C = X, etc...)? This is where you would get to
> make your own. Using the A-Z & 0-9 characters, you have 36 letters/digits
> to transpose the same way you did above. However, instead of making 1 = H,
> keep the next level numerical so it's easier to compute. The number 36
> divides 9 ways evenly (36/1=36, 36/2=18, 36/3=12, 36/4=9, 36/6=6, 36/9=4,
> 36/12=3, 36/18=2, 36/36=1). Using something not near the edge of that
> calculation such as 36/6=6, which we will use below, would be optimal
> (more secure). This table of cross-swapped chacters is our Reference.
>
> Step 2) For each level in your infrastucture (admins [5], superusers [4],
> groups [3], moderators [2], users [1]), a user's password would equal a
> specific value according to their asigned level. This is where you add
> another level of decryption by dividing the password up into segments much
> like a MAC or IP address. Each segment would be a different value and the
> total of all segments would be the value equivilent to that user's level
> (see numbers in [] above).
>
> Example 1:
> Original Password: A9F4B8E5C7D6D6I 1KZH2LSG3
> Divided into Segments: A9F4-B8E5-C7D6-D6I1-KZH2-LSG3
>
> Example 2:
> Original Password: SRXMTQWNUPVO1I0 J2HZK3G4F
> Divided into Segments: SRXM-TQWN-UPVO-1I0J-2HZK-3G4F
>
> Now for simplicity's sake, each segment in Example 1 & 2 equals 14, giving
> the total value 84. Each group of two characters starting from either side
> equals 7 (Example 1: A9, F4, B8, etc... all equal 7). Both examples are
> equivilent in level and about the middle of the amount of passwords
> possible. Each segment can only be as high as 24 using our current
> Reference, giving the total segment value of 144 as the admin/root level
> value.
>
> In Example 1, I alternated from the outside on one side of my Reference to
> the other when finding the key. Example 2 was made from the same
> Reference, however I started from the middle and worked my way out, but
> both passwords have an IDENTICAL LEVEL VALUE.
>
> Using my Reference, you will be able to see how I was able to come up with
> these...
>
> A, G, M, S, Y, 4 = 1
> B, H, N, T, Z, 5 = 2
> C, I, O, U, 0, 6 = 3
> D, J, P, V, 1, 7 = 4
> E, K, Q, W, 2, 8 = 5
> F, L, R, X, 3, 9 = 6
>
> Now if we use the same Reference as just above, but now only allowing each
> segment to be a total of 13 (or even keeping one half of them at 14 and
> the others at 13), then you've just created a password inferior in
> security level to the ones in Example 1 & 2;
>
> Step 3) In my creation of the passwords used from my Reference, I never
> reused a letter. After each character I used from my Reference, I marked
> it as used and picked from another from the equivilant valued row.
> Additional security would be to generate the Reference randomly and pick
> randomly from the Reference when building passwords. DO NOT get fancy by
> multipling each neighboring segment.191,102 ,976 possibilities may sound
> good, but mathematically, YOU WILL come up with matching valued passwords
> that don't equal the same security level. If you were, some sort of
> control would have to be used to ensure that this would not happen, but
> would be a pain to code and simpler if not used at all.
>
> You can always build off of this example to increase the amount of
> possibilities or security, but this is not a patented design.
>
> Of course this is not what most people use when implementing HIBE/FHIBE,
> but allows you to be able to do the same thing.
>
> William[/color]

--
Forschungszentr um Juelich
email: R.Bauer@fz-juelich.de

http://www.fz-juelich.de/icg/icg-i/

=============== =============== =============== =============== ======
a IDL library at ForschungsZentr um Juelich

http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro.html

Hierarchical Group Oriented encryption

Hierarchical Group Oriented encryption

Comment

Comment