It would probably be a good idea to take installation media along with you, and make sure to hash it before you go, then keep the hash on your person. If my machine got grabbed for "inspection", I wouldn't trust the OS on it as far as I could throw it.

My thoughts exactly. Maybe Ender's Game is considered to be so by people under a certain age, but Starship Troopers is almost certainly THE quintessential classic military sci-fi book.

And I would also argue that The Forever War should be in the list somewhere above Card's book.

Heck, between the RPV's and the children, I'm almost hesitant to even call it a "military" book per se.

If the data is that confidential, you should probably look into an actual FIPS-certified network-connected HSM instead of rolling your own.

I did a project a few years back using nCipher NetHSMs (they've since been bought up, I believe) and they were quite cool technology. Even then, I think one of these devices was in the $25K range at most.

The great thing is, if you generate a key pair with one of these, you literally cannot get access to the private key to hand over to the government, even if you wanted to.

Actual answer: no.

The CSR (Certificate Signing Request) contains only the public half of the key, to be signed by the CA's key which results in the CA attesting that the information is verified.

The entity whose key was signed always maintains control of the private key. Which, to me, is the reason that public-key encryption is not "over". The NSA would have to strong-arm every single holder of an SSL key, not just the Certificate Authorities.

Granted, though, those private keys are not often held terribly securely - they're most often just files on a server that aren't even password-protected, because that requires an admin to type in passwords whenever the Web server is restarted. They COULD be held in an HSM, a hardware security module much like a TPM on steroids, but that's very expensive and difficult to set up.

However, none of this means that public-key crypto is broken. It's possible that individual sites could be compromised via this route (Facebook, Google, etc) but as a whole, no.

The hardware isn't from Icom, it's from DVSI and available, at least on paper, to anybody that wants to pony up for a pre-programmed DSP from them. The existence of the DV Dongle from Internet Labs completely disproves your statement.

Now, as I've previously posted, I don't like that it's a proprietary codec that is only implemented in hardware, but that doesn't mean "you need to buy decryption keys [...] from Icom". Let's keep this conversation factual, shall we?

Sadly, the protocol didn't allow for identifying the codec used for the voice bits, so even if one wasn't concerned about interoperability with normal DSTAR radios, it's not possible as the DSTAR radios will try (and fail) to decode the voice data that's encoded using Codec2, but try to decode it in AMBE.

I think we need a newer protocol anyway that is much more supportive of mixed voice and data comms - the only way to send data with a DSTAR handheld is by keying up voice, wasting most of the bits, and sending slow-speed data along with the voice bits. It's really tragic if you ask me, such a waste.

Not possible to do in software because the only implementation is in a DSP chip that must be purchased from the vendor.

I have much less problem with the use of a proprietary codec (although I do wish Codec2 had been available at the time or a good allowance was made in the protocol for changing codecs) than I do with the fact that the only implementation possible is in hardware. It very much limits flexibility in open-hardware and computer-based implementations relating to the protocol. Such a waste.

People keep wishing that other manufactures would implement DSTAR hardware - I hope they don't, as I'd like to see it replaced with something much more open, or at least flexible. As well, support for data transmissions was implemented very badly and IMHO as implemented it's a waste of bandwidth, because it should have much better data transmission support.

Um, actually, Jared A. Bruegman, ex-KC0IQN, of Bolivar, Missouri, was given a $10,000 Notice of Apparent Liability (NAL, FCC-speak for "you've been a bad boy, pay up") just a couple of months ago.

Info here.

No kidding. I consulted for a few days in Batesville, Indiana a few years back, and flew into (and out of) Cincinnatti, which was on DST while eastern Indiana was not. Luckily I left quite early for the trip back home, because I lost an hour on the drive! Easily could have missed my flight because of all this stupidity.

Count me in for completely getting rid of this madness. Crossing time zones I can keep track of, but not taking into account the fact that only half of one state doesn't feel like following the rules.

We just made changes to every system not so long ago when Bush decided to lengthen DST, and I don't recall the world ending. Now is a great time to do it while the experience is still fresh.

Or they did as of not very long ago at all - I had to recover my password on their site, and just about fell out of my chair when, instead of sending me a recovery link, they emailed me my current password.

Nowadays that password is a KeePass-generated random one.

Not a lot of change that I can see.

With IPv6, the smallest subnet that will be assigned is a /64 - meaning 64 bits of host addresses are possible within that subnet. Originally it was envisioned that those 64 bits would be the MAC address of the host, but people had a wee bit of a problem with that privacy-wise, for just this reason - exposing the MAC address of a system on the public Internet.

So, many, if not most, hosts nowadays choose a random value for their host ID, do the IPv6 equivalent of a gratuitous ARP to make sure it's not in use already (highly unlikely), and if not they use it. Many also change their address periodically by doing this again.

Nice advantage here: unless a given network is using DHCPv6 and logging the requests, this is all done on-the-fly with no logging and no discovery possible.

Wanna bet? VOIP + SWATting = win.

Dude, bad example.

If you were in that union, you would have noticed that 92% of your fellow workers voted against the company's offer.