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

[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

[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.

Re: What is you motivational to use OpenBSD

[Peter Nicolai Mathias Hansteen]

> 28. aug. 2019 kl. 16:32 skrev Mohamed salah :
> 
> I wanna put something in discussion, what's your motivational to use
> OPENBSD what not other bsd's what not gnu/Linux, if something doesn't work
> fine on openbsd and you love this os so much what will do?
> 

You’ll find a bunch of testimonials over at runbsd.info , 
mine is at https://runbsd.info/people/pitrh.html 
, with the essence being I found a high 
quality, security oriented, well documented (as in everything has a man page) 
system where everything just made more sense than the systems I had encountered 
previously. That still stands, even after 20+ years and exposure to a lot of 
different systems and environments.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: Userland PCI drivers possible in OpenBSD?

[Alexandre Ratchov]

On Fri, Jan 10, 2020 at 03:58:16AM +, Joseph Mayer wrote:
> Maybe this topic is better suited for tech@, you tell:
> 
> Is there some way I can implement PCI drivers in userland in OpenBSD?
> 
> On a quick Internet search, see some discussion for Linux and NetBSD
> e.g. [1] however nothing in OpenBSD.
> 
> I may be interested in operating some PCI device manually from my own
> program (run as root or user) in OpenBSD, and I can see this being of
> interest to others also, asking therefore.
> 

If you're developing a new driver and you want to do quick
edit->build->test cycles, you could expose in user-space the proper
minimal interface and develop parts (all?) of your driver in
user-space. This is useful especially if the device is poorly
documented or complex and requires many prototyping. Once you
understand the hardware and you're satisified with your design, you
could turn it into a kernel driver.

If you're talking about giving user programs direct access to the PCI
bus, the necessary isolation mechanisms are missing. Furthermore, no
matter if it's running in user-mode or in kernel-mode, the driver code
will do the same thing, so in most cases there's no benefit of running
it in user-space.

my 2 cents