Usefulness of offloading cryptographic hashing of passwords
I recently read an article from facebook on password cracking. It got me thinking about how useful dedicated hardware might be for hashing passwords. Source: http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ Fairly basic stuff (MD5, brute & dictionary), however there was some neat insight into "combinator" attacks which made me revisit several of my passwords. I've been thinking about how "breaches" with big companies could be avoided. One comment stuck out, "whatever vulnerability was used to dump the password database can also be leveraged to see the exact algorithm used to store the passwords in the database." Raises the question, how could you prevent this? At first I thought about kernel level protection, then realized I can't think of anything root doesn't have access to other than "proprietary" hardware. Suppose you had a PCI card that generated a digest from input. Without knowing the algorithm, you could safely hash a password for storage or comparison to storage. Any retrieval of your password database would be pointless without the algorithm, in turn the hardware itself. In the event of a database breach, you destroy the device. Am I over-thinking this? This might be a fun exercise with my Arduino on my OpenBSD machine.
Re: How to select NAT port variations.
On 8/7/2013 2:09 AM, Stuart Henderson wrote: Normally port-restricted cone, or with static-port it's similar to symmetric (but obviously static-port can't work when two internal machines use the same port). With increasing use of cgnat in some large service provider networks you can be sure to see more nat-related problems with v4 over time... Is VPN or IPv6 an option instead? IPv6 is not an option. I've been pushing for VPN, but this is the only software that would need it. From my experience a VPN is tough to setup when your endpoints use different hardware (brand/os). I'll be honest, I know little about it. I was never properly trained on it. For some reason I used to think "static-port" gave Full Cone NAT. After I realized my mistake, I was able to identify some connectivity issues.
How to select NAT port variations.
I'm dealing with old software that uses old NAT traversal techniques. I specifically need to select the NAT variation as defined by RFC 3489 (section 5). Generally I've used nat-to's 'static-port' option and gotten around this issue. After adding some clients host-side, it seems like NAT traversal isn't working. Suppose I have this NAT rule: pass out on $external_int from nat-to $external_int static-port What NAT variation does OpenBSD implement by default? Wikipedia page on NAT variation (port translation): http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation
Re: Compilers in OpenBSD
I've always taken for granted the compiler I used -- until I read this thread. I've used buggy compilers before, such as fxc. I was even greatly affected by a bug in gcc and Apple. Although it caused me to contentedly switch to Microsoft, I still did not acknowledge my compiler's performance. On 7/31/2013 3:19 PM, Miod Vallat wrote: Yet none of them dares to provide a long time support version. This surprised and shocked me. For an unknown reason, I expected this of gcc. As for clang/llvm my opinion is simple: If the effort to switch compilers is equally or exceedingly rewarded then it is a valuable endeavor. On 7/29/2013 12:48 PM, h...@riseup.net wrote: LLVM/Clang * BSD license - we're not stuck with the old GCC crap * The code is cleaner * Lack of linuxisms, better follows the standars * Much better error handling * Building the compiller itself is easier I this case, I feel there's only novel reward. The question arises, should we be dealing with this subject proactively or reactively?
Re: IDE disk erasing/zeroing at ~2.4MB/s
On 7/12/2013 5:12 PM, Alexander Hall wrote: use the raw device, /dev/rwd0c, not the block device. Tried: dd if=/dev/zero of=/dev/rwd0c bs=64k It runs at ~72MB/s. Thanks!
Re: IDE disk erasing/zeroing at ~2.4MB/s (full dmesg)
0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 it0 at isa0 port 0x2e/2: IT8718F rev 1, EC port 0x290 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 mtrr: Pentium Pro MTRR support vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on wd1a (b3cecc3a21d4131c.a) swap on wd1b dump on wd1b On 7/12/2013 3:50 PM, Nathan Goings wrote: I have a disk -- IIRC, Seagate Barracuda 160gb 7200RPM 8MB Cache SATA 3.0GB/s dmesg: wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors wd0 (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 hours, it's only running at ~2.4MB/s. CPU usage is about 30%. First, shouldn't SATA drives be sd0? (Looked in BIOS, can't find any SATA-to-IDE options enabled) Second, what can I do to speed it up? or troubleshoot it at least?
IDE disk erasing/zeroing at ~2.4MB/s
I have a disk -- IIRC, Seagate Barracuda 160gb 7200RPM 8MB Cache SATA 3.0GB/s dmesg: wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors wd0 (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 hours, it's only running at ~2.4MB/s. CPU usage is about 30%. First, shouldn't SATA drives be sd0? (Looked in BIOS, can't find any SATA-to-IDE options enabled) Second, what can I do to speed it up? or troubleshoot it at least?
Re: Handling nested partition mounts with NFS (/usr/src)
On 7/5/2013 8:50 PM, Andres Perera wrote: so yes that indeed seems like crazy things in windows The documentation says to send a HUP signal to mountd to reload the changes in /etc/exports. However, after making changes, I am still able to mount *and* open files from entries I removed in /etc/exports. Not only that, I've have been unable to share /usr/src successfully since the first try. Whether it's a Windows or OpenBSD problem, this isn't suitable for my needs.
Re: Handling nested partition mounts with NFS (/usr/src)
On 7/5/2013 7:33 PM, Andres Perera wrote: you want nested nfs mounts which nfsv3/2 can't provide the export is associated to the mount point, it won't cross device limits either put /usr/src in the same file system, or use another nfs host Thanks! I think for now, I'll just export /usr/src/sys so I can work on this driver. However, it's odd that I can't mount both (starting with /usr). I'm not sure if that's a limitation for NFS or NFS client services for Windows.
Handling nested partition mounts with NFS (/usr/src)
I just setup NFS, and have gotten it working with my Windows 7 machine. Basically, I'm working on a driver and want to use a graphical IDE. /etc/exports: # /usr -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0 /usr/src -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0 /mnt/drive2 -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0 (On windows) If I mount /usr, /usr/src is empty. I thought this was a permission problem (thus, -maproot=root), then I thought it was a partition problem (/dev/wd1f is mounted to /usr and /dev/wd1i is mounted to /usr/src). If I mount /usr/src alone, it works fine. Then if I mount /usr it continues to work. However, if I mount /usr then /usr/src, it displays empty. Can anyone explain this? More importantly, is there a better way to achieve this?
Re: Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
On 7/4/2013 10:27 AM, Remco wrote: It has an AUTOCONF_VERBOSE define that can be used to get more verbose output, though I don't remember how useful it is. Looking at config(8), I think you should be able to set it in your copy of the GENERIC file as: option AUTOCONF_VERBOSE=1 ugh, I enabled AUTOCONV_VERBOSE, but dmesg gets cut off. Here's the beginning of /var/log/messages Jul413:37:54 BinaryNet syslogd: start Jul413:37:54 BinaryNet /bsd: bing for pcn* ... Jul413:37:54 BinaryNet /bsd: >>> probing for siop* This is *after* the ralink card. Meaning the ralink output and my own are gone. >.<
Re: Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
On 7/4/2013 10:27 AM, Remco wrote: On Wednesday 03 July 2013 19:11:19 Nathan Goings wrote: ... I would think if the attach failed it would be in /var/log/messages. How would I debug this? If the attach is failing, I might try crafting it to use a different driver. (guess I should try printf) I usually use printfs in places where I'd like to get more info. It's been a while since I looked into kernel programming so I'm digging most of this this up from my memory: /sys/kern/subr_autoconf.c - here the matching/attaching magic happens. It has an AUTOCONF_VERBOSE define that can be used to get more verbose output, though I don't remember how useful it is. Looking at config(8), I think you should be able to set it in your copy of the GENERIC file as: option AUTOCONF_VERBOSE=1 ... Thanks! I was just about to ask how to get more verbose output. What is printfs? I can't find any information on it. My printf statements haven't been showing up, but I'm going to try AUTOCONF_VERBOSE before asking about that. I've been looking into kernel debugging. The only examples I could find are emulated systems. I've also haven't used gdb style debugging in a long time, I greatly prefer log output. Finally, Is there a way to re-test the driver match/attach without rebooting?
Re: Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
Thanks for your response! On 7/3/2013 1:07 AM, Remco wrote: AFAIK this is step one. Assuming you added the PCI IDs correctly, the driver's attach function should run. However, to the best of my understanding, you chose a more or less random attach function for your unsupported device. My guess is that the attach function didn't run, or hasn't got the proper support for your device and therefore fails, leaving you with a "not configured" device. (Frankly, step one should be to first compare drivers and see if OpenBSD has the code necessary to support your device and add the missing pieces, instead of semi-randomly trying to run some OpenBSD code on your unsupported device. Also beware of differences in how the code is licensed in case you want to literally copy stuff.) Ralink packages the 2860 and 3060 source code in their open source driver. OpenBSD's ral(4) uses the 2860 as the default or 'catch all.' This indicates that the 2860 might be suitable for the 3060. The odd thing is that the 2860 *and* 3090 vendor packages include '30xx.c' I would think if the attach failed it would be in /var/log/messages. How would I debug this? If the attach is failing, I might try crafting it to use a different driver. (guess I should try printf) Finally, I'm very knowledgeable when it comes to copyright and licensing laws. Vendor code is GNU GPL and might be a problem with the register tables and such.
Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
I purchased an Edimax EW-7128Gn that contains a ralink RT3060 chip and it's unrecognized. dmesg: vendor "Ralink", unknown product 0x3060 (class network subclass miscellaneous, rev 0x00) at pci4 dev 0 function 0 not configured The documentation says a/g/n but this is a b/g/n. Ralink's drivers use the same firmware across what is supported and the 3060. The linux drivers are grouped in the 2860/3062 (which is supported). Plus the official drivers are open source! So my plan was to force the 3062 (later the 2860) onto the 3060 and see if it worked. Otherwise compare the linux drivers between 2860/3060/3062/3090 and compare the OpenBSD ralink between 2561/2561S/2661/2860 (per sys/dev/pci/if_ral_pci.c) and make the required changes (EEPROM? microcode?) Here's my problem, upon updating /sys/dev/pci/pcidevs (also changed pcidevs.h and pcidevs_data.h, unsure how they are auto-generated) I then updated sys/dev/pci/if_ral_pci.c (and associated cardbus) for pci_matchid ral_pci_devices so that the 3060 is matched by the ralink driver (and by default switch case the rt2860 is used) I still get "unknown product 0x3060...not configured" in dmesg. pcidevs entry: (and correct changes in .h and _data.h) product RALINK RT30600x3060RT3060 and for completeness, I'm successfully building and installing a GENERIC kernal *and* userland. First, how do I correctly compile and associate a "not configured" product to a specific driver, and second, how do I debug such an association?
