Become a fan of Slashdot on Facebook


Forgot your password?
Check out the brand new SourceForge HTML5 speed test! Test your internet connection now. Works on all devices. ×

Comment Re:Blantant? (Score 5, Interesting) 177

A security researcher who goes around looking for ATM skimmers should know that the magstripe reader always goes along with a camera for the PIN pad, and that the electronics inside the card reader part aren't the whole story.

It's completely obvious once you look for it, once you know a skimmer was installed on the card slot, especially having another pristine ATM right next to it to compare. Nobody's going to blame someone for not noticing a skimmer in the first place, but once you know one was installed, yes, the PIN pad part is blatant.

Comment Re:Just as well (Score 1) 368

The ARM has nothing to do with game consoles. The PS4 and the Xbox One don't even use the ARM for their secure boot/DRM, they use something else (the PS4 uses the SAMU which is an LM32 derivative core inside the GPU portion, and I think the Xbox One uses more custom stuff). Read this libreboot page; the ARM is required to boot any modern AMD chip. Or this if you want a reference from AMD from last year. The PSP is very much alive and well and required to boot modern AMD chips.

Comment Re:Just as well (Score 5, Informative) 368

... and guess what, AMD CPUs have an extra ARM core in them, as well as multiple little cores of various architectures attached to the GPU. All running proprietary firmware.

Throwing random little CPUs at problems is nothing new. What makes you think the firmware in your PCIe WiFi card also can't access all main memory and be turned into a rootkit? What about the Embedded Controller on laptops, that runs even when it's off?

Yes, the state of firmware auditability of modern PCs is dismal. It's been like this for at least a decade. Yes, Intel does it one way, AMD does it another way, and just about every other peripheral on your board is also an attack surface. GPU? Dozens of little auxiliary cores (unrelated to the GPU unified shaders); Nvidia or AMD, doesn't matter. That USB 3.0 host controller? Probably runs firmware too. Ethernet? Yup, often has firmware these days. That LSI SAS controller? Full PowerPC core with enough oomph to run Linux itself. Your hard drive? 3 ARM cores, you can make them run Linux too. And all of those things can scribble all over your main memory unless you enable the IOMMU (except the HDD, that one can scribble all over your storage instead).

Sleep tight.

Comment Re:Generators (Score 4, Insightful) 637

Length doesn't matter. What matters is that you use a unique password for everything.

Using a unique password for everything is impractical without making your passwords random (for a secure definition of unique, i.e. you can't guess one password given another one). But once you make them random, it doesn't matter how long they are as long as they're at least 6 (if fully random), preferably 8 (if constrained) characters or so.

Why? Because your password doesn't have to withstand an offline brute-force attack. It has to withstand an online, over-the-network brute-force attack. If the attacker gets your password hash such that they can use an offline attack, they have already broken into that service and have all your data anyway. And, since you use different password everywhere, cracking your password on that service gets them nothing.

Passphrases used to directly generate or wrap encryption keys are the exception to this, of course. Those had better be long.

Me? I use a pwgen-generated password on all sites/services, with the defaults (8 characters, pronounceable), and write them down in an encrypted password file. It's great, because I end up easily remembering the ones I use often, and the rest I look up as I need them. Can you crack those offline? Absolutely. But I couldn't care less; if you already have the hash, there's nothing more you get by cracking it.

Comment Re:Why does this matter? (Score 1) 130

Yup, they don't have any Seagate 3TB drives this time around... because they were so bad they ditched them all late last year. Meanwhile, as you mention, the ST4000DM000 (at 2.54% failure, sample size 34k drives) is doing better than the WD drives. The ST4000DX000 stat is not statistically significant, as they don't have many of those drives.

Comment Re:Why does this matter? (Score 3, Insightful) 130

No, it will affect you if you choose to ignore the results and buy a *3TB* Seagate drive.

When will people stop picking stupid manufacturer sides when it comes to drive reliability? It has nothing to do with manufacturers and everything to do with models. *Every* drive maker has put out shitty models that fail in dumb ways, from HGST (ex-IBM)'s DeathStars to Samsung's firmware fail (I still own a bunch of HD204UIs with an unfixed firmware bug that eats data if you dare use SMART self-tests) to Seagate's 3TB failures. Picking manufacturer sides just means you'll get hit whenever they make the next broken drive.

If you actually look at their per-drive stats, you'll see that Seagate's 4TB drive is, so far, *more* reliable than WD's current drives. I have a bunch of those and they're mostly running fine - though I had one drop off the controller last weekend (came back after reboot), first failure in years, I need to look into that. We'll see. Right now, 4TB Seagates seem to be the best bang per buck with decent reliability. Next year it might be another brand/drive.

Comment Re:Apple Watch not fast enough... (Score 4, Interesting) 98

I have no idea what emulator he's using, but it gets the prize for slowest x86 emulator of the year. Windows 95 is *lightweight* compared to anything modern, even under an emulator.

Let's see, quick test here. Samsung Chromebook, which is a dual-core Cortex-A15 (ARMv7) at 1.7GHz. Let's set cpufreq cap to 500MHz (Apple Watch is 520MHz). Install Win95 on a PC under QEMU, copy it over to the Chromebook, compile QEMU (for some reason it's not in the Arch Linux ARM repo...), and boot it up.

Boot time, from qemu launch to desktop and no "hourglass" cursor? 90 seconds. Emulating a PC on a 500MHz ARMv7.

Okay, so the Apple watch probably uses a lighter weight core than the Cortex-A15 on the Chromebook, but still, that doesn't anywhere near account for this kind of discrepancy. Oh, and QEMU is actually emulating a full 64-bit CPU (which of course Win95 doesn't need).

Comment Re:No hacking required... (Score 1) 286

Actually, there is no EEPROM in the SoC. The ROM firmware is, well, a true mask ROM (the first stage), and the rest is loaded from external NAND flash. It's actually impractical to put EEPROM onto the same chip as a modern high-end SoC: it would be too cost-prohibitive or take too long to develop, because EEPROM needs special processing steps that regular CMOS chips don't. You'll never find EEPROM/Flash on a leading edge, high-end process, it's always older stuff. This is why eFuses and other OTP technologies are used, because some of them can be done without any special processing steps. And why just about any decently powerful device always has a little 8-pin flash chip to hold the firmware next to the main SoC. You only get embedded flash with low-end microcontrollers.

Some (particularly older) OTP chips are just EPROM (one "E") - the kind you erase with UV light - without the UV window. EEPROM is actually UV-erasable too, and one of the things often done to reset security "fuses" in EEPROM-based microcontrollers is to apply UV light in the right spot. Chip designers end up using shield metal above the bits, sometimes not very successfully (I recall one such chip was hacked by putting the light at an angle to get in under the upper metal shield). But this is the realm of lower-end microcontrollers with embedded EEPROM/Flash.

Comment Re:Didn't (Score 1) 286

Currently this is true, but with the oncoming invention and use of quantum computing, a key-recovery attack on 256-bit AES will become trivial.

Nope. Even assuming practical QC is coming, it only halves the practical key size for symmetric ciphers. 256-bit AES becomes as strong as 128-bit AES. You don't need a Universe worth of time then, just the entire power output of the Sun for a few seconds (under impossibly ideal circumstances). Still not going to happen. And that's assuming Landauer's principle applies the same way to qubits, which I'm not even sure it does - qubits might be more expensive to handle energy-wise.

QC breaks (currently in use) asymmetric crypto. It doesn't break symmetric crypto, only weakens it.

Even with 128-bit keys, keep in mind that the largest symmetric key ever broken was a 64-bit key, and that was broken by a large distributed computing project (70k hosts). For QC to break a single 128-bit crypto key (64-bit difficulty in QC), we'd need to have quantum computing power equivalent to that. That's probably half a century away - QC is in its absolute infancy. And that's for a single key. By then we'll all be using 256-bit crypto for everything and it'll be completely moot. I use 128-bit FDE at home for my most important data and I don't feel the least bit insecure. I might switch to 256-bit in a couple years when I upgrade my boxes again and then I'll be set for eternity (unless some catastrophic flaw is discovered in AES).

I'm curious though, why would you just erase the key after 10 attempts. Surely they could just add a full 13-pass erase of all the data, and reset the phone back to factory settings.

The battery wouldn't last long enough for a 13-pass erase of the data. The whole point of FDE with an erasable key is that if you erase the key you don't have to do an actual data wipe. In practice, wiping the key is as good as wiping the data. Breaking that kind of crypto is outside the threat model, and if you can do that, then there are many other things you can do that would break security in other ways. Assuming an attacker can't break AES-256 is perfectly reasonable.

Comment Re:Didn't (Score 1) 286

Or the NSA slipped a back door into the hardware and/or software allowing them access without needing the encryption key.

Unlikely, since Apple designed the chip and it's not manufactured in the US, and Apple controls the software end to end (it's signed).

It's also quite possible the NSA purposefully created a (known only to them) weakness in AES and how it generates "random" numbers to greatly reduce the key space they would need to search.

Unlikely, since AES neé Rijndael was designed by two Belgian cryptographers, has no "magic" unexplained numbers (unlike the Dual-EC-DRBG "random" number generator that we know the NSA backdoored, or the ECDSA curves which we suspect they might have), and has been extensively cryptanalyzed. AES doesn't "generate" any random numbers. It's a block cipher.

The NSA isn't some all-powerful entity. They're a bunch of sneaky bastards, but assuming they have backdoors in anything and everything is excessive application of a tinfoil hat. Snowden said so himself: good crypto works. And Apple are a bunch of paranoid bastards.

Slashdot Top Deals

Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth