Re: OpenBSD FAQ - Using S/Key - hash algorithm selection

2020-01-14 Thread Wolfgang Pfeiffer

Both links may be really helpful to gauge the hashes used for an skey
system, theoretically. So thank you for providing them.

But sadly, if I didn't miss anything, they do not describe the real
life circumstances needed for some successful attack on the skey
hashes. For example how much time is needed by which hardware to break
them? And what sort of access is needed for some successful attack: do
the attackers need to sit in front of the machine to succeed?  May
network access to the targeted machine be an option to crack skey?
And how much hardware power is needed for a break-in via network
access - how much time does that approach take to succeed?
Etc. etc. ...

A real life scenario in a public library, where a user is logging in
to his computer: If he uses his permanent password to do that, with at
least as many phones/cameras around him as there are people in this
room, chances his machine might get compromised seem to me a lot
higher than using an s/key password to log in - no matter what hash
was used to initialize the skey system. Correct?

Much better example: I can prove that a human arm is a very useless
body part because it's so easily vulnerable by a crash with a train
coming with 100 mph. Theoretically I'm fully correct. But it's bs
anyways ...

So I'd like to see more of a real life scenario where using certain
hashes for skey to login mean more risk than using e.g. a standard
permanent password. So far I didn't find one.

What did I miss?

Regards,
Wolfgang

On Sat, Jan 11, 2020 at 10:15:48PM -0500, Daniel Dickman wrote:




On Jan 11, 2020, at 3:24 PM, Anders Andersson  wrote:

While perusing the OpenBSD FAQ I came across the S/Key login system
and noticed that there are three possible hashing algorithms to choose
from: MD5, SHA1, and RIPEMD-160.

Instinctively I wouldn't want to use any of these. RIPEMD-160 seems
like the only one that hasn't been broken, but that's probably because
no one really cares as much as they do with MD5 and SHA1.


Collision attacks are not the same as preimage attacks. The latter are much 
harder.  See: https://en.m.wikipedia.org/wiki/S/KEY#Security

Here’s an article that also may be of interest:

https://electriccoin.co/blog/lessons-from-the-history-of-attacks-on-secure-hash-functions/



But of course, it depends on how they are used. Is this a case of when
it's fine to use them, or is it simply that nobody uses S/Key anymore
so there's no real incentive to change them?

Just being curious, I didn't even know S/Key existed until a few minutes ago.








Re: OpenBSD FAQ - Using S/Key - hash algorithm selection

2020-01-11 Thread Daniel Dickman



> On Jan 11, 2020, at 3:24 PM, Anders Andersson  wrote:
> 
> While perusing the OpenBSD FAQ I came across the S/Key login system
> and noticed that there are three possible hashing algorithms to choose
> from: MD5, SHA1, and RIPEMD-160.
> 
> Instinctively I wouldn't want to use any of these. RIPEMD-160 seems
> like the only one that hasn't been broken, but that's probably because
> no one really cares as much as they do with MD5 and SHA1.

Collision attacks are not the same as preimage attacks. The latter are much 
harder.  See: https://en.m.wikipedia.org/wiki/S/KEY#Security

Here’s an article that also may be of interest:

https://electriccoin.co/blog/lessons-from-the-history-of-attacks-on-secure-hash-functions/

> 
> But of course, it depends on how they are used. Is this a case of when
> it's fine to use them, or is it simply that nobody uses S/Key anymore
> so there's no real incentive to change them?
> 
> Just being curious, I didn't even know S/Key existed until a few minutes ago.
> 




OpenBSD FAQ - Using S/Key - hash algorithm selection

2020-01-11 Thread Anders Andersson
While perusing the OpenBSD FAQ I came across the S/Key login system
and noticed that there are three possible hashing algorithms to choose
from: MD5, SHA1, and RIPEMD-160.

Instinctively I wouldn't want to use any of these. RIPEMD-160 seems
like the only one that hasn't been broken, but that's probably because
no one really cares as much as they do with MD5 and SHA1.

But of course, it depends on how they are used. Is this a case of when
it's fine to use them, or is it simply that nobody uses S/Key anymore
so there's no real incentive to change them?

Just being curious, I didn't even know S/Key existed until a few minutes ago.