Reducing the chance of collisions in known encryption systems

From: Simon Beckett (simon.beckett_at_gmail.com)
Date: 11/25/04 

Date: 24 Nov 2004 20:29:21 -0800

Greetings all,
       First of all this is my first post on here so please forgive me
if i do something wrong.

I am still very new to the world of cryptography and cryptanalysis and
probably dont have the mental requirements to pursue the deeper more
mathimatical world of the algorithms themselves so for now i'm playing
with how they are used.

An idea they have been playing around with is a way of increasing the
difficulty of finding a useable password by making collisions a
trivial matter.

Here are the details.

Currently on a password system (like the unix login system) passwords
are stored as the resulting hash and should this list of hash's be
captured then it is a stones throw form being compromised as all that
is needed is any password that will result in the captured hash.

What i am pondering is using a ruleset defined upon installation to
render this ineffective and to make it so that only the password as it
was ORIGINALLY entered will unlock the system, instead of ANY password
that results in the same hash.

The following is used.
1. A password in both plain text and encrypted form
2. A very long string of random characters

Firstly a rule is decided upon so that we dont make this terminally
one way. This rule is used to define the passwords position.

in this example we'll use the password "kryptos" and and for
simplicity the rule will be "the sum of all the alphabetical position
of every second letter"
in this case 11, 18, 25, 16, 20, 15, 21 (forgive me if i'm wrong i'm
at work and my attention span is being limited) totalling 126.

Now this means that our actual password hash is located 126bits (or
126 character spaces in see above about attention span) into our big
string of random numbers.
 
so we now have something that looks like
"j092fewii3021c32ur2r32XXXXXXXXXXXXXXX09u3r2j0c0fm2jf032j302"
where XXXXXXX is the actual hash of our chosen password. Again this is
an example and is not accurate.

When this system is used for logging in the login app will apply the
ruleset to our plain text password, store the result, encrpt the
password to a hash and compare it to our random string starting from
the position defined by the rule set.

Obviously if any other password is used to say cause a collision then
this would result in a different starting position and as such a
failed login attempt.

Should someone capture the entire password list they would be
presented with nothing but a set of large seemingly random strings
which will ,after what i hope is long and painful analysis, reveal
itself to be well random and rather unhelpful. The only way to brute
force it would be to brute force every possible grouping of characters
in the string until a match is found.

Now i agree this is probably a candidate for the "security by
obscurify" bin, but it struck me that the correct and creative use of
obscurity can compliment a systems existing non-obscurity based
security.

If this idea holds up and is deemed "worth a try" i'll be looking into
developing a peice of demonstration software so that the idea could be
further strengthened.

Would ny of you be interested in giving me some constructive feedback
for this idea? If it all possible i'd like the salvage any parts that
arent a right off, so if you can spot problem please also try and
suggest a solution, or atleast a way to one.

oh and any responses direct to my email appeal to the lazy sod in me.

My thanks in advance.

Simon Beckett
obsolete at obsolete dot au dot com (yes the au and com are actually
backwards on purpose not just for anti spam)

Relevant Pages

  • Re: Base36
    ... static string tokens = ... But - I don't think you want all those silly characters in the product key. ... I should be able to recalc the hash at the client ... > conversion to long so I can pass each long to the BaseXX converter to get ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to omit blank spaces in the text?
    ... Private Sub Command1_Click ... Dim ssql As String, ssql2 As String, ssql3 As String, trimname As String ... character set from &H21 to &H7E provides for ASCI alpha numeric characters ... >> When the password is first created you calculate the hash and store>> that, ...
    (microsoft.public.vb.general.discussion)
  • Re: Making a hash of things...
    ... > require that you first collect the string and operate on the string ... > while scanning the characters in the identifier. ... have the length computed when you want to apply a hash. ...
    (alt.lang.asm)
  • Re: Hash table in C++? STL?
    ... > But we need hash only the first maxchars characters. ... As hash functions go, this is better than many, but less than ideal ... size_t buckets) { ... early in the string. ...
    (comp.lang.cpp)
  • Wierd behaviour of function strcspn
    ... similar to printf (please Dont ask me why this, ... string into as many parts as there are format specifiers. ... characters one by one from one string to an another final string .. ...
    (comp.lang.c)