Hi all,

I have one of those situations where not only do I not know the answer,
but I am uncertain what the questions is, lol. I need to create an
application that for the following need:

My company frequently holds trainings in large conference rooms with
300 or more people. We are struggling to find an efficient way to
document who was in the training. Sign in sheets or laptops are too
cumbersome.

I'd like to do something like this. At the end of the training, cards
are handing out with a code. Later, the employee can go to a website
and enter the code and get credit for the training. All the codes
should be different, randomnly generated, and only good for one use.

I don't have any idea how I could generate these random codes off of a
key (maybe the course name/code) and then reverse the algorithm to
accept the code back to confirm the user attended the class.

This may be the wrong place to ask about it, but I'm hoping someone can
point me in the right direction. I have searched password generator,
license key generator, and cryptography to no avail.

Also, this does not need to be hack-proof. It only needs to stop the
casual goofball for getting credit for something he didn't do.

Thanks all!

The quickest, and not necessarily best, way I can think of to accomplish
this is to create a number of new GUIDs for each person attending (e.g., if
300 people attend, you'll need at least 300 GUIDs), store them in a database
for that class, print them on cards, and hand them out. When they access
your website, register that GUID with the person's name. According to the
documentation, GUIDs have an extremely low probability of being duplicated
anywhere else in the world, and it allows you to avoid the process of
generating random passwords, license keys, or cryptography.

Thus, you create a training course in your database. Assuming people have
to let you know ahead of time that they're attending, you create a number of
GUIDs equal to the number of registered attendees, plus extras to account
for last minute registrations. If you have a course for only 40 people,
maybe generate an extra 5 to 10 GUIDs. If you have a course for 300 people,
maybe add an extra 30 GUIDs. A second table would store the course ID with
the GUID. A third table would store the registered attendees. When the
attendees register via the web, you copy the GUID into the registered
attendee's record and delete it from the GUID table.

If you have to associate the GUID with a specific attendee, then store the
GUID in the registered attendees table, and hand out that GUID with the
attendee's name on it to that attendee when s/he shows up. But this method
adds the overhead of searching through cards to find the specific attendee's
name instead of just handing them out.

Hope this helps. Maybe someone else knows a better solution.

Dave

[quoted text, click to view]

Hi,

Funny that you asked this :-).

I have a very elegant and secure solution to you problem which I want
to publish in LNCS or similar publication. Right now I'm working on a
couple of articles describing the solution that I'm going to submit to
one of the upcoming international crypto conferences (the one that have
submission deadline which I manage to catch). I have the program code
and test data results ready; I have collected all the necessary
material and almost done with security proof. I can't publicly disclose
solution here because if I do I would risk my submission to be refused,
but if your company is really interesting in such scheme, you can
contact me by e-mail - I'll be glad to provide consulting and implement
the whole scheme for your company.

-Valery.
http://www.harper.no/valery

[quoted text, click to view]