You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alfred Reibenschuh <al...@gmx.net> on 2007/07/24 02:19:05 UTC

[triplesec/hauskeys] issues

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

hi!

as i found out lately triplesec is in a state of flux
and elecharny mentioned on irc that it would be a good
time to raise some issues.

i'd like not to step on somebodies toes so please forgive
some uncertain language constructs as english is only
a second language to me.


my particular area of interest in triplesec is the hauskey midlet.


* the current midlet uses a plain numeric-only pin to decrypt
the seed-storage and since most pins tend to be 4-6 digits,
a possible attacker is able to precompute all possible keys
for all seeds ever issued in this fashion in under one minute.

* the use of the pin-string as the key-byte-array is an unfortunate
decision since it increases the chances of actually using weak and
semi-weak des-keys which are prone to cryptographic shortcut attacks.

* the use of the des-cipher is an unfortunate decision since
it can be brute-forced with under U$D 10,000 hardware in under
10 days.

* des has a nominal strength of 56 bits (nowadays weak) whereas
the usage of a four-digit pin reduces this to 13 bits!


proposed solution:

* use randomly keyed rsa/elgamal cipher (>=2048bits) for seed.

* use pin combined with an iv to keywrap random-key (aes/3des).

* make pin alpha-numeric with 4-12 chars.

this would mean that the seed itself can only be brute-forced
and only with "large prime factorization" :-)

as long as a good keywrap with iv is used the only attack would be
brute-forcing the 256-768 bit key/iv-space :-)

precomputation would only be possible if the large storage
requirements could be met and than only for a single known
issued token-seed, making it equal to brute-force :-)


cheers,


fredo
- --
Schonmal davon gehoert, dass nicht jeder linux user gleich ein
programmierer ist, der alles, was er selber braucht, auch selber
programmiert, installiert, patched, hacked oder portiert?

Urks?  Das ist doch nur eine Legende.....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpUV5jKJMaHhpyr4RCEhEAKDCJrGH6hEBnTTNv1d8If626jgdJACeK41k
VBX7cvAje1+6pjG/gjJARA4=
=nrqD
-----END PGP SIGNATURE-----

Re: [triplesec/hauskeys] issues

Posted by Alex Karasulu <ak...@apache.org>.
On 7/25/07, Alfred Reibenschuh <al...@gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alex Karasulu wrote:
> > Eventually yes but let's see a couple patches to evaluation if you are
> > not a
> > butcher :).  Does not
>
> i've been called a brute but not a butcher ...


Have not called you one yet :).

Thanks for the patch saw it on the JIRA.  I will try to take a look soon but
bear with me.  Perhaps if I don't get to it someone can take a look and
apply the patch.  Christine could you validate for me if I cannot find time
to logon?

Regards,
Alex

Re: [triplesec/hauskeys] issues

Posted by Alfred Reibenschuh <al...@gmx.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alex Karasulu wrote:
> Eventually yes but let's see a couple patches to evaluation if you are
> not a
> butcher :).  Does not

i've been called a brute but not a butcher ...


> sound like it - but after a couple patches I should be able to determine
> enough.  So start putting
> these issues you have in JIRA then knocking them off and attaching the
> patch
> to a JIRA issue.
> As advice try to keep the task small and directed so it's easier to
> evaluate
> what you're doing in
> your patch diffs.  Also avoid unnecessary refactoring or formating of code
> that obscures the gist
> of what you're doing in the diff.

ok, i'll sort them out, bt this will take a while.


> Great!  I think your security concerns can lead to some positive things for
> the midlet design.
> 
> Would love to have someone that is interested in the midlet involved. 
> There
> are so many
> advances we can work on with the midlet.  Right now it's just minimal and
> generic. 

yet is has potential.


> Also I wanted to put a self destruct setting into the midlet that destroyed
> the credential info in
> the phone or locked up the midlet some how if the user tried to break in by
> brute forcing the pin.
> Say N consecutive unlock events lead destroy the secret key and
> counter.  If
> user gets it right
> before N failures consecutively the failure counter clears.  The counter
> should be persisted
> across restarts.

destroying the HOTP-INFO in the jar isnt possible,
but you have already implemented lockup if the pin
is entered a certain number of times.


> I also have some ideas on leveraging bluetooth too but you may not be
> interested in that.

yet this kind of 'featuritis' could be counter-productive.


> Just install IDEA or Eclipse, JDK 1.5.0_xx and check out tsec and start
> working on the code.

ah, eclipse is already my usual poison so no pb.


> If you have issues gimme a ring.

i will.



fredo
- --
Schonmal davon gehoert, dass nicht jeder linux user gleich ein
programmierer ist, der alles, was er selber braucht, auch selber
programmiert, installiert, patched, hacked oder portiert?

Urks?  Das ist doch nur eine Legende.....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp66UjKJMaHhpyr4RCDduAKDEhSSk2VTTfOzuPVLPLm02Zhuo5wCgi45y
rGmU5yBQr52CGlsM8CjVRlI=
=jpvx
-----END PGP SIGNATURE-----

Re: [triplesec/hauskeys] issues

Posted by Alex Karasulu <ak...@apache.org>.
Hi Alfred,

On 7/24/07, Alfred Reibenschuh <al...@gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alex Karasulu wrote:
> > All good points.  You interested in working on the midlet?
> >
> > Alex
> >
>
> if that means svn commit access (*drool*) ...


Eventually yes but let's see a couple patches to evaluation if you are not a
butcher :).  Does not
sound like it - but after a couple patches I should be able to determine
enough.  So start putting
these issues you have in JIRA then knocking them off and attaching the patch
to a JIRA issue.
As advice try to keep the task small and directed so it's easier to evaluate
what you're doing in
your patch diffs.  Also avoid unnecessary refactoring or formating of code
that obscures the gist
of what you're doing in the diff.

ok, seriously, why not.


Great!  I think your security concerns can lead to some positive things for
the midlet design.

Would love to have someone that is interested in the midlet involved.  There
are so many
advances we can work on with the midlet.  Right now it's just minimal and
generic.  For example
we could product midlets that take advantage more more phone features based
on the version of
the phone.

Also I wanted to put a self destruct setting into the midlet that destroyed
the credential info in
the phone or locked up the midlet some how if the user tried to break in by
brute forcing the pin.

Say N consecutive unlock events lead destroy the secret key and counter.  If
user gets it right
before N failures consecutively the failure counter clears.  The counter
should be persisted
across restarts.

I also have some ideas on leveraging bluetooth too but you may not be
interested in that.

what environment should i have installed to make this happen?


Just install IDEA or Eclipse, JDK 1.5.0_xx and check out tsec and start
working on the code.

If you have issues gimme a ring.

Regards and welcome :),
Alex

Re: [triplesec/hauskeys] issues

Posted by Alfred Reibenschuh <al...@gmx.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alex Karasulu wrote:
> All good points.  You interested in working on the midlet?
> 
> Alex
> 

if that means svn commit access (*drool*) ...

ok, seriously, why not.

what environment should i have installed to make this happen?


c

fredo
- --
Schonmal davon gehoert, dass nicht jeder linux user gleich ein
programmierer ist, der alles, was er selber braucht, auch selber
programmiert, installiert, patched, hacked oder portiert?

Urks?  Das ist doch nur eine Legende.....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpZuijKJMaHhpyr4RCARVAKDQiBzh3cRRiJE751+3FlHF/N5tmACdEtUe
SxZ9LQ4ZJhCsffJyb9decVs=
=FvFv
-----END PGP SIGNATURE-----

Re: [triplesec/hauskeys] issues

Posted by Alex Karasulu <ak...@apache.org>.
All good points.  You interested in working on the midlet?

Alex

On 7/23/07, Alfred Reibenschuh <al...@gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> hi!
>
> as i found out lately triplesec is in a state of flux
> and elecharny mentioned on irc that it would be a good
> time to raise some issues.
>
> i'd like not to step on somebodies toes so please forgive
> some uncertain language constructs as english is only
> a second language to me.
>
>
> my particular area of interest in triplesec is the hauskey midlet.
>
>
> * the current midlet uses a plain numeric-only pin to decrypt
> the seed-storage and since most pins tend to be 4-6 digits,
> a possible attacker is able to precompute all possible keys
> for all seeds ever issued in this fashion in under one minute.
>
> * the use of the pin-string as the key-byte-array is an unfortunate
> decision since it increases the chances of actually using weak and
> semi-weak des-keys which are prone to cryptographic shortcut attacks.
>
> * the use of the des-cipher is an unfortunate decision since
> it can be brute-forced with under U$D 10,000 hardware in under
> 10 days.
>
> * des has a nominal strength of 56 bits (nowadays weak) whereas
> the usage of a four-digit pin reduces this to 13 bits!
>
>
> proposed solution:
>
> * use randomly keyed rsa/elgamal cipher (>=2048bits) for seed.
>
> * use pin combined with an iv to keywrap random-key (aes/3des).
>
> * make pin alpha-numeric with 4-12 chars.
>
> this would mean that the seed itself can only be brute-forced
> and only with "large prime factorization" :-)
>
> as long as a good keywrap with iv is used the only attack would be
> brute-forcing the 256-768 bit key/iv-space :-)
>
> precomputation would only be possible if the large storage
> requirements could be met and than only for a single known
> issued token-seed, making it equal to brute-force :-)
>
>
> cheers,
>
>
> fredo
> - --
> Schonmal davon gehoert, dass nicht jeder linux user gleich ein
> programmierer ist, der alles, was er selber braucht, auch selber
> programmiert, installiert, patched, hacked oder portiert?
>
> Urks?  Das ist doch nur eine Legende.....
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGpUV5jKJMaHhpyr4RCEhEAKDCJrGH6hEBnTTNv1d8If626jgdJACeK41k
> VBX7cvAje1+6pjG/gjJARA4=
> =nrqD
> -----END PGP SIGNATURE-----
>