Prev: It's not science, it's sci.
Next: AES counter content and same key/nonce
From: JR on 3 Feb 2010 00:21
Hi,
I am programmer who hasn't worked much with cryptography.

I need to build a quick & dirty system for achieving the following

- I have 1 central machine + many machines at different locations.
The machines may not be connected to the central machine at all times, hence
the need for an offline solution.

- A person will phone up an admin at the central location with the
following information
- His employee Id
- The company he works for
- The number of hours he needs to use the resource for

- The admin needs to input this info to the tool & generate a token/
key which can be conveyed over the phone.
- The person will key in this token/key into a program running on
the machine at the remote location & he will get access to a resource
for that much amount of time
- The key shouldn't be too long - i.e. a 16 char key would be great,
anything
longer may be problematic.

This is a quick & dirty solution I thought up for this. There is 1 symmetric
key shared between the central machine & all the remote machines.
This is the algorithm to generate the key.
--------------------------------------------------------------------------
- Create a string concatenating the EmpId & Company Name.
- Hash the string to get a smaller string.
- Truncate the hash to say 8 bytes.
- Calculate current UTC time + no of hours to block resource for.
Divide by 60 to get it in minutes (not worried about seconds). Not sure
how many
bytes I will need for storing this.
- Append the 2 strings (truncated hash + time).
- Encrypt this string with the symmetric key.
- Base 64 encode this to get a License Key kind of string.
-------------------------------------------------------------------------
- The client machine tool will accept the empid & compname from the
user & the license key he got over the phone.
- The tool will base64 decode the key.
- Will decrypt the result.
- Will extract the truncated empid+compname part of the result.
- Will calculate it's own empid+comp name truncated hash from
the user input.
- If it matches, that means the license key is good.
- Then it will Extract the date/time part of the message to find out
how long he has reserved the resource.
- Will calculate the empid+compname truncated hash.
-------------------------------------------------------------------------

This is something quick & dirty I need to code in a couple of days.
Cracking the security is not a big issue. Just need to prevent non-tecnical/
non-savvy users from cracking it.

This whole system is going to be in place only for 3 months till a bigger
project
will be deployed which also includes this.

Can someone analyse this & help me out with the following info
- What hashing can I use
- What encryption can I use to get a small key (16 bytes or so)? The
main consideration is that the client tool should be able to compute the
resource end-time from the key.


From: Kristian Gj�steen on 3 Feb 2010 07:14
JR <p(a)pnp.com> wrote:
>I need to build a quick & dirty system for achieving the following
>[...]
>This is a quick & dirty solution I thought up for this. There is 1 symmetric
>key shared between the central machine & all the remote machines.

Use

k = HMAC-SHA256(master-key, company)
token = truncated HMAC-SHA256(k, end time || employee id)

The program deployed at the company has k and computes HMAC-SHA256(k,
end time || employee id) for various likely end times until it finds
one that matches.

>This is something quick & dirty I need to code in a couple of days.
>Cracking the security is not a big issue. Just need to prevent non-tecnical/
>non-savvy users from cracking it.

--
Kristian Gj�steen
From: Ilmari Karonen on 3 Feb 2010 07:40
On 2010-02-03, JR <p(a)pnp.com> wrote:
>
> - A person will phone up an admin at the central location with the
> following information
> - His employee Id
> - The company he works for
> - The number of hours he needs to use the resource for

> - The admin needs to input this info to the tool & generate a token/
> key which can be conveyed over the phone.
> - The person will key in this token/key into a program running on
> the machine at the remote location & he will get access to a resource
> for that much amount of time
> - The key shouldn't be too long - i.e. a 16 char key would be great,
> anything longer may be problematic.

I would use a truncated MAC for this. That is:

- The employee tells the admin his company name, employee ID and the
number of hours he needs.
- The admin concatenates these to a single string S.
- Using a secret key K known to the admin and the remote machine, but
not to the employees, and some standard hash function, the admin
calculates HMAC(K,S), truncates the result to, say, 32 bits, and
tells that to the employee.
- The employee keys in the same info they gave to the admin, plus the
truncated MAC, into the machine, which repeats the MAC calculation
and checks that the results match.

You can adjust the information encoded into the string S to match your
requirements: for instance, you may wish to include some kind of
timestamp and/or a machine identifier in there, etc.

For passing the MAC to the employee over the phone, you probably want
to use base 36 or 32 rather than base 64 -- that way you don't need to
distinguish between upper and lower case letters. Even better would
be to use a list of, say, 1024 common and easily distinguishable
English words to encode the MAC as three or four words.

For computing the HMAC, just about any commonly used cryptographic
hash will do. Even MD5 is still considered secure for use in HMAC
(and certainly so for truncated HMAC), but any of the SHA family of
hash function will do just as well.

The number of bits you should truncate the MAC to depends on how
paranoid you are. In practice, even 16 bits should be enough to make
it unlikely for anyone to get a valid token by trial and error (unless
they automate the process; and if they can do that, it would probably
be easier for them to just hack the machine to extract K or bypass the
check entirely). 32 bits should be plenty, and 64 should be well
beyond the reach of even automated guessing.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
From: JR on 3 Feb 2010 21:50

"Kristian Gj�steen" <kristiag+news(a)math.ntnu.no> wrote in message
news:hkbpae$kv4$1(a)orkan.itea.ntnu.no...
> JR <p(a)pnp.com> wrote:
>>I need to build a quick & dirty system for achieving the following
>>[...]
>>This is a quick & dirty solution I thought up for this. There is 1
>>symmetric
>>key shared between the central machine & all the remote machines.
>
> Use
>
> k = HMAC-SHA256(master-key, company)
> token = truncated HMAC-SHA256(k, end time || employee id)
>
> The program deployed at the company has k and computes HMAC-SHA256(k,
> end time || employee id) for various likely end times until it finds
> one that matches.

Thank you for your suggestion. However, the end time can be at 15 minute
intervals
& it could be quite long - i.e. they can reserve for say a week.
So won't computing HMAC-SHA256 for all these times be rather time consuming?

>
>>This is something quick & dirty I need to code in a couple of days.
>>Cracking the security is not a big issue. Just need to prevent
>>non-tecnical/
>>non-savvy users from cracking it.




From: JR on 3 Feb 2010 21:53

"Ilmari Karonen" <usenet2(a)vyznev.invalid> wrote in message
news:slrnhmirmj.vdj.usenet2(a)melkki.cs.helsinki.fi...
> On 2010-02-03, JR <p(a)pnp.com> wrote:
>>
>> - A person will phone up an admin at the central location with the
>> following information
>> - His employee Id
>> - The company he works for
>> - The number of hours he needs to use the resource for
>
>> - The admin needs to input this info to the tool & generate a token/
>> key which can be conveyed over the phone.
>> - The person will key in this token/key into a program running on
>> the machine at the remote location & he will get access to a resource
>> for that much amount of time
>> - The key shouldn't be too long - i.e. a 16 char key would be great,
>> anything longer may be problematic.
>
> I would use a truncated MAC for this. That is:
>
> - The employee tells the admin his company name, employee ID and the
> number of hours he needs.
> - The admin concatenates these to a single string S.
> - Using a secret key K known to the admin and the remote machine, but
> not to the employees, and some standard hash function, the admin
> calculates HMAC(K,S), truncates the result to, say, 32 bits, and
> tells that to the employee.
> - The employee keys in the same info they gave to the admin, plus the
> truncated MAC, into the machine, which repeats the MAC calculation
> and checks that the results match.
>

Thank you for your reply.
However, in this case conveying the number of hours can be rather rather
time consum


 |  Next  |  Last
Pages: 1 2 3
Prev: It's not science, it's sci.
Next: AES counter content and same key/nonce