Forgot your password?
typodupeerror
Security Data Storage Windows Hardware

Encryption Cracked On NIST-Certified Flash Drives 252

Posted by timothy
from the whoopsie-daisy dept.
An anonymous reader writes "USB Flash drives with hardware based AES 256-bit encryption manufactured by Kingston, SanDisk and Verbatim have reportedly been cracked by security firm SySS. These drives are advertised to meet security standards suitable for use with sensitive US Government data (unclassified, of course) as emphasized by the FIPS 140-2 Level 2 certificate issued by the US National Institute of Standards and Technology (NIST). It looks likes the Windows-based password entry program always sends the same character string to the drive after performing various crypto operations."
This discussion has been archived. No new comments can be posted.

Encryption Cracked On NIST-Certified Flash Drives

Comments Filter:
  • by Anonymous Coward on Tuesday January 05, 2010 @01:40PM (#30658430)

    One weakness in the entire crypto-system can bring the whole thing down.

    • by hey! (33014) on Tuesday January 05, 2010 @02:21PM (#30659020) Homepage Journal

      Only? It's *mainly* defects in the rest of the system that tend to bring things down.

      Algorithms, once they get to the point where the experts trust them, are very seldom broken in the everything-laid-completely-bare way that faulty system design gets you. It's usually more like "could be broken with a week of supercomputing time ten years from now" or "can calculate a hash collision for certain specially constructed messages" variety of crack.

      Of course once you get to that point, you have to assume that some really bright people will find a way to generalize the fault in the algorithm. If they'd broken AES, or even found an unexpected weakness in it, that'd be *huge* news. Instead, what they've found appears to be a classic case of plain old brain damaged design.

      If the article is to be believed, the researchers found a really, really stupid flaw, the kind a non-expert like I could understand and probably exploit with not much effort. I would paraphrase this way: all these drives *effectively* have exactly the same key, but that fact is obscured by the software.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      I used to do FIPS, Common Criteria and Interac certifications.
      For starts we were paid by the manufacturer of the device so every device passed. There was one case where a product was so obviously flawed we decided not to take the money and they device was certified by another certification shop.
      Second, the cost for the certification is fairly competitive and the competition has driven the price down to the point where the money paid just barely covers doing the paper work. The actual investigation of the

  • by NeutronCowboy (896098) on Tuesday January 05, 2010 @01:41PM (#30658462)

    Can anyone explain to me why the disk manufacturers chose to reinvent the wheel, instead of using Truecrypt? As far as I know, Truecrypt encryption hasn't been broken yet.

    • by jimbobborg (128330) on Tuesday January 05, 2010 @01:46PM (#30658532)

      These aren't disks, they're USB thumb drives. The folks who "cracked" it just figured out a way to bypass the password and send a specific string that ALL of these devices use to access the data on these USB thumb drives. This seems to be endemic to these things. The info isn't encrypted, it's just locked with a password.

      • Re: (Score:3, Informative)

        by NeutronCowboy (896098)

        No, it's actually encrypted. The problem is that the command to unencrypt the data is always the same. In other words, a small little widget can sit between the password program and the encrypted disk, and just send the right command string, regardless of what password was entered. Instant decryption.

        But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.

        • Re: (Score:3, Informative)

          by OscarGunther (96736)

          Assuming your last comment wasn't a rhetorical question, you already know the answer to this: Because the perceived value-add of selling an encrypted drive allows them to charge more than simply bundling TrueCrypt with a bog-standard USB drive. The public justification would be that their software is easier to use (and, if they're feeling particularly full of themselves, more secure).

          • Re: (Score:3, Insightful)

            by ragethehotey (1304253)

            Assuming your last comment wasn't a rhetorical question, you already know the answer to this: Because the perceived value-add of selling an encrypted drive allows them to charge more than simply bundling TrueCrypt with a bog-standard USB drive. The public justification would be that their software is easier to use (and, if they're feeling particularly full of themselves, more secure).

            But with a minimal amount of work they could simply take the source, rename it and give it a pretty interface, and never have problems like this?

            • by DavidTC (10147)

              Yeah, that's what gets me. I mean, it's one thing if they were selling special software and didn't want to have to distribute it, which the GPL would make them.

              But they're selling a drive. I mean, it's just as much work any other way.

              Edit TrueCrypt's interface, put it to autostart from the tiny cleartext partition (Using that autorun U3 trick), have it only look for a specially marked partition on the other drive, and mount it, or prompt for password and format it if the partition is blank.

              Tada.

              Instead,

        • Re: (Score:3, Interesting)

          by jimicus (737525)

          No, it's actually encrypted. The problem is that the command to unencrypt the data is always the same. In other words, a small little widget can sit between the password program and the encrypted disk, and just send the right command string, regardless of what password was entered. Instant decryption.

          But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.

          If it was properly encrypted, the decryption would be carried out on the device using a key supplied by the host PC and the device wouldn't be physically capable of decrypting it without the key. As it stands, the most charitable reading of this is that it IS using AES encryption, but it always uses the exact same key regardless of what the enduser does in the software.

          • Re: (Score:3, Insightful)

            If what you are saying is true, that it uses the same encryption key for all devices, that would have to be by "Design", or worse, negligence. I seriously doubt that the engineers for this thing thought one key to rule them all would be acceptable, which leaves us with "Design".

            However, I'm reminded of the old addage, "Any sufficient level of incompetence is indistinguishable from malice".

            My view is that sufficient levels of incompetence should be treated exactly like malice. And in this case the company(co

        • by vlm (69642)

          But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.

          Certain corporations want to "poison the well" of encrypted USB drives. Doesn't really matter why and thats not the point of this post. The end result of this incident is every clueless PHB now "knows" that its "impossible" to make a properly encrypted USB drive, and somehow the corps that are intentionally poisoning the well believe they will profit off that incorrect belief. Maybe they want to drive (bad pun) a competitor out, maybe they lack the patents their competitors have, who knows. Maybe they a

          • by vlm (69642)

            Oh, bad of me to reply to one of my own posts, but maybe they need to poison the market for encrypted USB drives because they're about to release a different kind of competing product, like maybe a USB hub that encrypts the traffic flowing thru it to any brand or model of USB drive. Or maybe coincidentally only works with same manufacturers drives.

            Maybe they may want to ruin the sub market of encrypted USB drives because contract terms are getting unfavorable for them in that sub market, and coincidentally

        • by geekmux (1040042)

          No, it's actually encrypted. The problem is that the command to unencrypt the data is always the same. In other words, a small little widget can sit between the password program and the encrypted disk, and just send the right command string, regardless of what password was entered. Instant decryption.

          But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.

          If it's not yet that obvious, let me sum up the definition of "regardless of what password was entered" in two words: Big Brother.

          Perhaps this is the fine print part of "FIPS" certification we never heard about...the master key.

          • by vlm (69642)

            If it's not yet that obvious, let me sum up the definition of "regardless of what password was entered" in two words: Big Brother.

            Perhaps this is the fine print part of "FIPS" certification we never heard about...the master key.

            Yeah, thats the good news, we know about Big Brother's master key in these software encrypted drives..

            The bad news is we don't know about Big Brother's master key in the OTHER drives.

      • by PylonHead (61401)

        The info isn't encrypted, it's just locked with a password.

        Yeah, that's what the story seems to say. But that makes no sense... Why have an AES 256-bit hardware encryption system if you're going to store the data unencrypted? I mean.. it's all just bits as far as the memory chips are concerned.

        • Re: (Score:3, Interesting)

          This makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event you forget your password.
          • by vlm (69642)

            This makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event you forget your password.

            Far more likely: makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event law enforcement/military/courts would like to see whats on your drive.

          • by gumbo (88087)

            Anyone who sees a encryption device/service that offers the option of recovering your data without the passphrase should already know to run away, quickly. That's admitting right in the open that they have serious weaknesses.

        • Re: (Score:3, Funny)

          by sjames (1099)

          More to the point, what's the point of a super lock if you're going to tape the key to the door?

    • by bamf (212) on Tuesday January 05, 2010 @01:57PM (#30658742)

      If you set up Truecrypt in portable-mode on a USB key so it acts like these off-the-shelf keys, then it needs administrator privileges to work. That's a big problem for a lot of people.

    • by gad_zuki! (70830) on Tuesday January 05, 2010 @02:29PM (#30659122)

      Portable Truecrypt has problems. The user will import their private key or at least have it somewhere they can get to it or use conventional cryptography. So there's a lot of security vulnerabilities right there. Oh, forgot to delete your private key? Now Im cracking the conventional encryption that protects it. TrueCrypt portable requierd admin privs:

      Also note that, as regards personal privacy, in most cases, it is not safe to work with sensitive data under systems where you do not have administrator privileges, because the administrator can easily capture and copy the sensitive data, including the passwords and keys.

      However, users without administrator privileges cannot encrypt/format partitions, cannot create NTFS volumes, cannot install/uninstall TrueCrypt, cannot change passwords/keyfiles for TrueCrypt partitions/devices, cannot backup/restore headers of TrueCrypt partitions/devices, and they cannot run TrueCrypt in portable mode.

      The idea with these drives is that the app can be run from the drive itself, so no extra software or training is needed. No key management. So that really just leaves us conventional cryptography, not public/private key. The problem of having security on your USB drive that gets plugged into various computers that you might not have control over and may be running trojans is tough to solve. Application level encryption is probably the best way to go but it requires standard installs and trust of the host computer.

      Youre better off just carrying a netbook or other trusted security device with an encrypted drive and sharing the files via conventional methods with the host without giving the host all your data - email, ftp, web, plaintext transfers, etc.

  • by Anonymous Coward

    "12345"

  • Oops. (Score:3, Funny)

    by Brian Recchia (1131629) <brian@recchia.name> on Tuesday January 05, 2010 @01:43PM (#30658482) Homepage
    Looks like they forgot the ROT13
  • I got an IronKey from my parents for Christmas. I haven't used it on a Windows machine yet, just my MacBook Pro and Linux EeePC at home and my iMac at work. The article doesn't mention whether or not that platform is affected by a similar type of issue or not -- is anyone more familiar with this that can weigh in on that? I'd be kind of pissed if my brand new toy turns out to just be a toy after all, but IronKey is also FIPS 140-2 certified. Do the tree products noted just use the same original vender f
    • Re: (Score:3, Interesting)

      by RemyBR (1158435)
      The Ironkey should not be affected. It uses a different approach: first of all, the data on the drive is really encrypted, the drive is not only "locked" with a password. Secondly and most important, there's no validation of the password happening outside the drive (i.e. on a windows/linux/mac application). The application only lets you input your password, which is then validated by the drive itself via a ROM routine.
    • by Andy Dodd (701)

      I would expect that the same thing that makes it cross-platform (drive handles authentication and unlocking, not the software) would make this particular attack (some dumbass offloaded authentication to the software) irrelevant.

    • Re:IronKey? (Score:5, Informative)

      by IronKey Dave (1134607) on Tuesday January 05, 2010 @03:51PM (#30660360)
      IronKey D200 and S200 models are validated to the much more demanding FIPS 140-2 Level 3. The products that are the subject of this hack are validated to Level 2. They are all in fact manufactured by SanDisk. Previous authors are correct, their architecture has serious design flaws. They are relying on the host PC to do password verification, and essentially using a static code to tell the device to unlock. Basically it's a back door to all of those affected SanDisk, Kingston and Verbatim devices. I will be posting an FAQ later today on the https://www.ironkey.com/ [ironkey.com] website describing the flaws and how IronKey's architecture does not have these issues. IronKey validates all passwords in hardware. We have password replay prevention and encrypted USB command channels. We also use a hash of the password to decrypt the data AES key, so it's cryptographically impossible to unlock an IronKey without the password. Finally, IronKeys store encryption keys and brute force counters in a hardened CryptoChip. The SanDisk, Kingston and Verbatim products store them in Flash memory, which isn't even part of their FIPS 140-2 security policy. Dave
      • Re: (Score:3, Insightful)

        by Jon Abbott (723)

        Thanks for posting this update. I've always had respect for IronKey and that level of respect just went up a few notches.

  • by JazzyJ (1995) on Tuesday January 05, 2010 @01:47PM (#30658546) Homepage Journal

    The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.

    • I was going to say nearly the same thing. The encryption was not cracked, merely bypassed.

      • by jandrese (485)
        If it can be merely "bypassed" then it doesn't seem like it was encryption at all, just password protection. If this is the case, then they might be in trouble for misrepresenting their product in the advertising.
        • As someone else pointed out, all of the USB drives use the same encryption key. SySS engineers discovered that through the Windows program. Now they can simply use that encryption key to bypass the encryption.

          To me this would be like discovering that all Master Locks used the exact same key. So the validity of the lock would not have been compromised, but it would certainly be quite easy to bypass any protection it offers by using one of the widely availability other keys.

    • If I understand the article correctly, the access application in effect ignores the entered password, and instead - probably as a result of miserable software design - uses a fixed-string password for the encryption/decryption. In that case, it's not so much a compromise as an own-goal by the fools who wrote and tested (?) the Windows access application. The encryption implementation itself is probably fine if it's given decent keys...

  • by tibman (623933) on Tuesday January 05, 2010 @01:50PM (#30658602) Homepage

    Seems that they did in software what should have been done in the hardware. The USB hardware should consider itself safe and the host machine suspect.. atleast in my mind. ATMEL has some good chips like: http://atmel.com/products/securerf/cryptocompanion.asp?family=646 [atmel.com]

    • Re: (Score:3, Informative)

      by John Hasler (414242)

      > Seems that they did in software what should have been done in the hardware.

      Thereby shaving $.93 off their manufacturing costs.

    • What difference does it make? As long as the data is really encrypted on the drive, either way the cpu is going to have access to the plain text, and in some ways it's better to do the encryption on the cpu: no plaintext over USB foils usb-attached listening devices. Depending on how it's implemented and what you need the data for, it's even possible to never have plaintext in RAM.

      The article seems to imply that the data is not, in fact, stored on the drive using the claimed AES cipher, or if it is, the p

      • by tibman (623933)

        Yeah, the article didn't really explain the technical details. From what i got the device needs the software to authenticate (hash matching?) then decrypts the drive's contents with a generic key. But they seem to still require the use of the authentication program? Which means they can't just decrypt the contents with a default key.

        Doing decryption on the host is good for the reasons you listed but that would only be for symmetric keys. I would rather not transfer a private a-symmetric key to the host

      • by DavidTC (10147)

        That's the thing that gets me about USB hardware encryption. I can't figure out the damn point.

        The only possible advantage is that hardware encryption could maybe work without admin privs.

  • some data (Score:5, Informative)

    by HBI (604924) <kparadine@gmail.cTEAom minus caffeine> on Tuesday January 05, 2010 @01:51PM (#30658626) Homepage Journal

    First, here's the NIST list of approved 140-1 and 140-2 modules [nist.gov].

    Note that they approve the module and not the access software. The flaw is in the access software. Therefore, 140-2 compliance or approval isn't proof that your data is safe. It just means that some approved form of encryption is implemented by the crypto module. It appears that the modules in question were given some form of TEMPEST examination as well, but once again, that means nothing in terms of the access software.

    • Sigh, no (Score:3, Informative)

      by Anonymous Coward

      Correct stuff was already explained above by someone else:

      http://it.slashdot.org/comments.pl?sid=1498504&cid=30658760 [slashdot.org]

      The flaw is in the hardware, at least according to TFA. It works like this:

      1) SW: OK, let's decrypt the drive, HW, you gives me dat0rz
      2) HW: not so fast SW, you have to confirm if I should give the dat0rz
      3) SW: Oh, right silly me, you give me challenge hash then
      4) HW: Here u go
      5) SW: kthx
      6) SW: User, I need pass to verify challenge hash
      7) US: here's pass, now give me dat0rz!
      8) SW: Working

    • Re:some data (Score:4, Insightful)

      by mick232 (1610795) on Tuesday January 05, 2010 @02:39PM (#30659258)
      The flaw clearly is in the device! The access software is irrelevant because anyone can copy or modify such software. The device must protect the data regardless whether the access software has been compromised. If the FIPS approval does not consider this, then it's nothing more than a marketing gag.
    • The flaw is in the access software.

      No, it's not. If the hardware gives up the data without requiring the encryption key, the hardware is flawed.

      • by gumbo (88087)

        My reading is that the hardware decrypts and gives up the data when the right key is sent. However, the right key is unrelated to your passphrase, it's a standard key for either that device or all devices (the article is unclear on this.)

    • As you will see from the rebuttals below, you are just wrong.

      Put the real problem is whose head will roll for this, This needs to attract punitive damages.
    • Re: (Score:3, Insightful)

      by Alsee (515537)

      Note that they approve the module and not the access software. The flaw is in the access software.

      As a programmer and hardware geek with a passing familiarity with crypto. It is quite clear what this device is doing (and what it is not doing). In fact the design issue here is so fundamental and blatant that I hesitate to even call it a "flaw". The hardware does not actually offer any crypto security at all, none.

      The hardware is doing one of two things, although I don't have enough information to be sure whi

    • Re:some data (Score:4, Insightful)

      by Facegarden (967477) on Tuesday January 05, 2010 @05:09PM (#30661566)

      First, here's the NIST list of approved 140-1 and 140-2 modules [nist.gov].

      Note that they approve the module and not the access software. The flaw is in the access software. Therefore, 140-2 compliance or approval isn't proof that your data is safe. It just means that some approved form of encryption is implemented by the crypto module. It appears that the modules in question were given some form of TEMPEST examination as well, but once again, that means nothing in terms of the access software.

      Actually, the flaw is indeed in the modules. They ALL use they same unlock key. I'd say that makes them flawed. The software is not helpful - it just obscures the fact that they all use the same unlock key by asking for a unique password that it converts to the common unlock key - but as unhelpful as the software is, it isn't the issue.

      To put it another way, there is no way of fixing the software to change the fact that all of these drives can be accessed with one known key, which means its not the software that is broken, its the keys.

      Of course, it doesn't help that the software gave up that key, so that is certainly a flaw but if the modules all had different keys it wouldn't be as helpful and it certainly isn't as big as a problem as the modules all being the same!
      -Taylor

  • by calmofthestorm (1344385) on Tuesday January 05, 2010 @01:52PM (#30658636)

    It involves a predictable post with the same predictable replies all the time...sort of like Fox news, or slashdot;)

    Alternatively, instead of challenge-response it's greeting-response.

  • Does anyone else feel like standard ways of encrypting USB Drivers are urgently requires so we no longer need to depend on third party vendor software to do the job [badly]?

    Unfortunately only Microsoft or to a lesser degree Apple could roll out such a standard since nobody else have the leverage.

    • by jandrese (485)
      It's something I'd like to see in the USB3 spec: A standard (but optional) way for the driver to pop up a window and ask the user for input. Make sure Microsoft is on board and agrees to patch Vista and Win7 include it in the first release of their USB stack as well. It would be more difficult to support on Linux, but not impossible. Backwards compatibility would be a concern though. Maybe a better place would be in the ATA driver? I certainly wouldn't mind seeing more laptop drives with built-in hard
  • by georgewilliamherbert (211790) on Tuesday January 05, 2010 @01:57PM (#30658744)

    I don't believe why any portable secure drive needs to or should trust its host computer. This is a particularly stupid implementation, with an obvious and blatant exploit. But the host computer could by definition be compromised, and could intercept or store / cache or misbehave generically with the password you enter to get in.

    Put a thumb-key sized numeric or hex keypad on the device, and make the owner punch in the code on insertion into a host device. One could still physically break into and tap the keys somehow, if the device is stolen and then returned without the owner knowing, but the user interface moves to right next to the data...

    • by tgd (2822) on Tuesday January 05, 2010 @02:17PM (#30658972)

      If you don't trust the host computer, why would you unlock the device at all?

      Once its unlocked and mounted, anything on the computer can access it anyway.

      • by iammani (1392285)

        If you don't trust the host computer, why would you unlock the device at all?

        The GP talks about the device trusting the host. Not about the user trusting the device or the host. To clarify further, I always use my encrypted device on machines I trust, but it doesn't mean the device should assume any machine it is plugged into is my trusted machine and it can unlock right away.

        • it doesn't mean the device should assume any machine it is plugged into is my trusted machine and it can unlock right away.

          Why? If only the user knows the key, and a given host machine sends the correct key to the drive, then obviously the user has decided that machine is trustworthy by entering the key in to it.

          • “any machine it is plugged into” != “a given host machine sends the correct key to the drive”

    • Re: (Score:3, Insightful)

      by plover (150551) *

      While I agree that trust belongs on the device (via a device-based keyboard), you still have to trust the host computer to not abuse the trust by copying the now-unlocked data or otherwise tampering with it. You are still at risk if you unlock the device and plug it in to a coffee shop PC.

    • This is stupid. A password must be 20 random characters MINIMUM to provide just 128 bit key strength. Nobody's going to type such long passwords on a tiny thumb-drive keyboard all the time.

      • by Rich0 (548339)

        You could store the key in hardened memory (resistant to retrieval at the physical layer), and encrypt that key with a shorter passkey.

        A short password is perfectly secure if the device wipes the full key upon some small number of password failures (rendering all data stored on it lost). Of course, that opens up a DOS avenue, but if somebody can get their hands on the key they can already destroy it pretty easily anyway.

        Where this kind of model should REALLY be used is with ATM and credit cards. Put a dis

      • Would it be practical to hash their password with SHA-256 and use that as the 256-bit key?

        Of course, there’s an obvious question: Is it easier to reverse a SHA-256 hash of a 64-bit password than it is to crack the encryption of 64-bit AES-encrypted data? harder? the same?

        (Obviously a short password will always be poor from a security standpoint. However, short of making people use 256-bit passwords, you have to compromise somehow.)

      • Re: (Score:3, Informative)

        by IronKey Dave (1134607)
        You are incorrect. FIPS validated products cannot use the password for key generation. Instead, they must use a random number generator to create the AES key (eg 256-bit key). They password is used to gain access to the key. So a short password can be used, yet you still get 256 bit encryption. As long as brute force password protection counter is also implemented in hardware and cannot be rolled back, you do not need very long passwords (eg. set a 3 try limit). Also, you should encrypt the random AES
  • Insider (Score:3, Informative)

    by dbrez8 (999142) on Tuesday January 05, 2010 @02:35PM (#30659198)
    As someone who works in the secure flash drive space, maybe I can shed a little light on some questions/comments I see above..

    First and foremost the vulnerability described in this article is related to only the secure flash drives stated in TFA. There are several others available that do not have this vulnerability because instead of password matching in software, they match in Hardware of Firmware, run on the drive itself. Are there others within the industry that may be susceptible? Probably, but all secure flash drives certainly are not. Look to only use drives with password matching done on-chip (HW/FW).

    How could a FIPS 140-2 certified flash drive have this vulnerability? Well FIPS is great to prove you use certified encryption algorithms, authentication methods, and so on, but FIPS does not certify the whole system. This is one of those very important security areas that fall outside of the FIPS umbrella. In the future look for additional certifications that will encompass the entire system rather than just the encryption like FIPS..

    Why not just use TrueCrypt?? TrueCrypt is a great product, there is no doubt. But at its core, TrueCrypt is a software encryption container for your data. There are some inherent shortcomings with software encryption on USB flash drives.
    1. Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive.
    2. Though it may work well for consumers that *want* to have their data secure, TrueCrypt would be a nightmare in an enterprise setting. Users could format the drive, or store files outside of the encrypted partition just to make things easier. This is not possible on secure flash drives with forced data encryption via hardware. with these drives an Admin knows that if he sees a drive by company X, that the data on it must be secure. Just to name a couple..

    I hope this is helpful to some.
    • Re: (Score:3, Insightful)

      by vlm (69642)

      1. Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive.

      You're assuming your short production run / limited power / simple architecture / limited heat dissipation hardware is faster than running it in software on a commodity processor, which RAID card manufacturers have falsely been pushing for years (decades now?). Think about it, it implies a USB sized and USB powered gadget runs faster than the PC its plugged into.

      Also assumes the limiter to overall system speed is processing the data. Feeding "a couple megs" to a multicore processor running "several gigs"

  • Once there has been established a perfect unbreakable encryption, they will then have to work on establishing perfect and unbreakable people that deal with the information; and that's much harder to do.

    I think it is a smart move to keep putting up walls of security with encryption; people should try to maintain their secrecy for whatever purpose that is... But history shows that the encryption will most likely be broken. And given the day that the encryption cannot be broke, more focus will be applied to

New crypt. See /usr/news/crypt.

Working...