7 Replies to “Forward!”

  1. “it would sure be nice if President Obama put a stop to this.” –
    Mother Jones is coming down hard on the poor little president!

  2. So can RSA’s customers sue them for about $20million dollars? They did not receive what they paid for if the encryption was deliberately compromised.

  3. Limiting the output of the PRNG is a classic method for screwing over a crypto algorithm. Reduces the key space enormously.

  4. Isn’t Big Government awesome?
    If I didn’t suck at math I’d be selling do-it-yourself encryption kits today.
    By the way, for those of you getting Smart TVs for Christmas, if you don’t want the TV watching you back I advise a strategically placed Post-it note over the built-in camera. Also, be aware that it transmits every single button-press on the remote back to the manufacturer. And by extension, the NSA.
    It knows when you are sleeping,
    it knows when you’re awake.
    It knows if you’ve been bad or good,
    so be good for Goodness’ sake!”
    NSA is coming to town.

  5. Doesn’t surprise me in the least and that’s just one of the reasons I only use open-source encryption algorithms. The RNG is key in any encryption scheme and, for those who have open source encryption programs, I’d strongly advise replacing ones RNG with a certifiably secure RNG.
    The current source of random numbers I have is a Geiger counter. Given the mere 16 cpm background radiation where I currently live, that represents a rather small bit rate (that is if one creates a random bit based on whether the previous interevent interval was greater or lesser than the current), or one can utilize the low bits of the interval as random bits. Lots of web sites on the internet have information to test the randomness of ones RNG output and I’d suggest utilizing a non-US web site to do so. The other option is to time the inter-event intervals of the RNG utilizing a 1 microsecond clock (which I have implemented in a Propeller chip) but then one has the issue of Geiger tube dead time at high count rates and it’s interesting that a cryptography book I’m currently reading has about 1/3 of the book dedicated to the problem of generating truly random numbers.
    Another means of generating pseudorandom numbers is utilizing the low bits of the TSC if one has the ability to put a filter into ones IDT to immediately grab the value of the TSC when an interrupt occurs. For windoze users, this is not possible unless one figures out how to disable the “safety” features of windoze which, from WinXP forward consider the IDT as one of the areas of RAM which is off-limits to non-M$ system programs. Very annoying as given the high clock speeds of modern CPU’s, the lowest bits of the TSC when one times keystrokes or mouseclicks are very likely random as the effect of a 3 GHz clock rate is to randomize even what would appear to be macroscopically periodic events. Anyone who decides to do this should be aware that the TSC lowest bits are fudged by the CPU depending on the current clock speed as almost all new CPU’s have variable clock speeds as a power saving measure. Thus one would have to ensure that CPU usage was 100% when creating random numbers via this method.
    For the truly paranoid, the one totally unbreakable form of encryption is a one-time pad (OTP). True, one does have the problem of hiding the OTP from prying eyes, but this is a certifiably unbreakable encryption method if one has files on ones laptop which one wants to take over a border and not reveal ones encryption key. In some countries, refusing to reveal an encryption key will get one put in jail and thus one mails a USB flash drive which contains the OTP data to an individual in the country one is visiting. Then, one can say with absolute veracity, that one doesn’t know the encryption key to the data on ones hard drive. This data is completely immune to brute force attacks but can be decrypted with a simple xor operation with the encryption key on the USB flash drive.
    Right now I would not utilize any form of commercially available closed source program for encryption of ones data. For simple web browsing one can utilize the built in secure sockets capability of ones web browser, but for storage of information one wishes to not be visible to the NSA spooks, use only open source tools for which one has perused the source code and compiled the source code oneself with a trusted compiler (one often overlooked back doors into code is via a contaminated compiler and thus one should also review the compiler source code and preferably use a stripped down compiler which one would use to compile the source code and then use a disassembler to verify that no malicious code had been injected into the executable file by the compiler one had used.) For OTP encryption, the compiler is irrelavent as one is coding just a simple xor operation between two files and here the problem is securely separating the encrypted data and the encryption key (which has the same length as the data file).
    If you think I’m being overly paranoid about this, just remember who we’re dealing with and the main fear I have in this area is that I’m not paranoid enough.

  6. May I suggest also using pre-Internet hardware to compile things on? Intel and AMD have been partners with the NSA since the Clinton years.
    Old Sun and SGI workstations are fast enough and can be had for a song on EBay/Craigslist. Best of all, they use old Motorola and Sparc CPUs. And run Linux.
    You’re not paranoid when They really are out to get you.

Navigation