Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Intel

Intel to Build Encryption Capabilities in Chips 44

Will Johnston sent us a link to a CNNfn article where you can read about Intel's plan's to incorporate encryption into it's microchips. I'm not sure about this one: The paranoid in me starts quivering, but then again, standard encryption sure would make a lot of this stuff a lot easier. What do you think?
This discussion has been archived. No new comments can be posted.

Intel to Build Encryption Capabilities in Chips

Comments Filter:
  • Just what I want - a chip using an unknown weak algorithm, which the NSA probably mandated have a back door so somehow they can read anything encrypted on it...

    No thanks. Gimme gnupg any day...

    --

  • Can be found at the Intel press release site. It appears that Intel will be working with RSA on incorporating RSA technology such as BSafe.

    This actually makes me feel marginally better. RSA is sometimes fairly good about publicizing their algorithms. They are a pretty reasonable player in the encryption marketplace.
  • Encryption should be implemented as a software module of some sort. That way, if the algorithm gets broken, the module can be swapped out and replaced with a newer module that hasn't been cracked yet. I believe this is already done.

  • by gavinhall ( 33 )
    Posted by Bill, the Galactic Hero:


    Yuggek muh duhdordik, cnuup buhyoyay hmerp. Gwee, fubbub spinkmadoodink -- qwrrr xoxop. Splunggi jojingloo meezoom:

    ?) thukthukthuk
    #) krebbler gnay "inihimijimipibi"
    ;) oooooooaaaaaaaaaayyyy


    - Bonk
  • no matter what encryption they use, it'll have to be considered weak. there isn't a SINGLE case in history where "security through obscurity" actually worked.
  • ... if the algorithm they use isn't a standard one, you'll be forced to use Intel chips to use the algorithm. This says nothing, of course, about "is the algorithm 'secure'?" ...

    also, if after a few years, the algorithm becomes cheap to brute force, you'll be required to upgrade.

    so, in summary: encryption in the chip? feh! chips are fast enough today to handle software encryption. it tends to be more flexible as well.
  • I heard on headline news that the government will be able to see what was encrypted.

    No thanks.

    ----
  • First midi was exported from software to hardware, then 3D graphics were exported to hardware, then device dependant drivers were exported from the OS to the hardware. Now encryption is exported from software to the hardware. What does it mean for the future of the programmer?
  • Easier is N E V E R more secure.

    I still use PGP v2.06 because I know 5.0 has the govt. backdoor built in that Zimmerman had to give to the feds if he was going to be allowed to sell it...although this GNUgp sounds promising..
  • It's sure to be government-breakable, ie insecure.
  • If hardware encryption becomes the standard this will kill off any Open Source encryption momentum. You'll note that the Wassenaar agreement specifically doesn't address Open Source. see:
    www.gnupg.org. So if everyone gets hooked on hardware encryption it's one step closer on the slippery slope to 'clipper' type key escroe our friends at the NSA have been pushing all decade.

    I won't be buying into that garbage, nor would I trust Intel or any other huge corporation with my privacy.
  • Don't make the mistake of assuming that "encryption capabilities" means an algorithm. Their "3D capabilities" are not implemented as a renderer in silicon. Their "multimedia capabilities" do not mean there is a codec on the chip.

    Most likely, they will be introducing new instructions to make implementation of encryption simpler/faster.

    Of course, that's just what we need. More instructions. Instructions are to processors as features are to software. Selling points, branding, market differentiators. Usually unnecessary.

    Kinda makes me nostalgic for the whole RISC vs. CISC debate. We need a whooooole new category for these beasts.

    x86 + MMX + Katmai + DES = SCISC (super-complex instruction set computer)?

    Or is it VCISC?
  • From the rumors (again: rumors) I her, it's primarily going to be random number generation. As people probably know, getting good random numbers from a deterministic machine is really tough. Intel's new chips will provide real random numbers (I imagine through radioactive degredation, but I don't know). This would be an incredible boon to possibly the toughest problem in crypto (next to trust management).

  • Software encryption is the only way to go, since it takes away the power from other entities.

    Imagine if the OS were built into ROM, and you couldn't run anything but the Operating System that comes with the computer..

    If you have a compiler and open source, you never need to worry about back doors in a particular encryption algorithm.

  • ... had an article about this very topic this morning and how the Government is making it oh-so-difficult to export such chips. I wish I had read the article in futher depth. The Oregonian website (as painfully slow as it is) hasn't posted the article.

    My $0.0000000002 anyway.
  • IIRC and if it's what I read about a month or so ago. Not meant for standard encryption duties, only to tie a registered product to a specific processor. Scares the piss out of me -- what if you upgrade your processor? What about dual processor systems? What about just buying a new box and moving all your software over?

    --
  • Um, software developers aren't quite imbecilic enough not to have a move-license-across-chips service; they *know* people upgrade.

    Unique CPU IDs are lovely, because it means Intel can have a database of what speed rating they sold each CPU at and you immediately get rid of people relabelling CPUs (since the buyer just checks with Intel what their CPUID was speed-rated at) without having to kill off the overclockers (who check what their CPUID was speed-rated at, then ignore that).

    Hardware RNG is good because it removes a very hard-to-analyse source of possible insecurities (which Netscape ran into a few years back) from your crypto algorithms.
  • until someone figures out a way to get to the key (which, after all, must either come with the software, or be derivable from your chip's ID), and to decode programs once and for all. give it 3 months after the chips come out.

    not that I care much anyway, this would apply to proprietary s/w, which I don't depend on.

  • If my computer used hardware based encryption, I would use PGP and the hardware based encryption. It would be preferable to sending it plaintext. And if the government decides it wants to peek in on my email, PGP will make sure their plans fail.
  • Many people have mentioned that doing this may have some kind of potential backdoor by the government. Which is probably more than likely.

    However, my argrument with this is that speed will suffer. Intel processors use CISC technology, 1 instruction per cycle. Adding encryption routines would send the processor though the backlogs of hell.

    If Intel was to do encryption, they would have to switch to a RISC system, and then the problem is possibly going to turn into the Y2k problem. Chips that use the same base code, including the encryption routines, and then someday, some major worm comes along and kills the encrypt, and shuts down the processors of the world.

    IMHO: Hell no.

"Why can't we ever attempt to solve a problem in this country without having a 'War' on it?" -- Rich Thomson, talk.politics.misc

Working...