Slashdot Mirror


Encryption Market Opening Up

MeriaDuck writes "Found this article on Cryptome, the Clinton administration plans to announce next week that it will permit U.S. software companies to sell their most sophisticated encryption systems to countries in the European Union without any licensing or review." Well its a start anyway.

9 of 72 comments (clear)

  1. This was predicted some time ago by rdl · · Score: 5

    Cypherpunks and others predicted many years ago
    that the government would slowly relinquish
    control over crypto as more and more of a commercial market developed.

    PGP was never much more than a curiosity -- no
    one used it for large-scale commerce systems,
    and most of the users could be pointed to by
    the government as privacy nuts or criminals.

    SSL, despite inherent weaknesses, has made
    crypto essential in e-commerce. The e-commerce
    lobby (sites, vendors, end-users) exposed the
    masses to crypto, and now depends upon crypto.
    When users started demanding 40 or 128bit crypto
    to keep their credit card numbers secure, that's
    when crypto became widely deployed.

    The next step is building crypto into the very
    fabric of the Internet, in IPsec, and then making
    that a "checklist item" for purchasing decisions.
    Once people are only willing to buy products with
    security designed in, the government will have
    little choice but to allow its widespread use and
    export.

    (I'm waiting for encrypted cellphones, like
    those being designed by Starium, to
    be available...)

    1. Re:This was predicted some time ago by billstewart · · Score: 3
      PGP's real importance was that you _could_ use it, and you could get it easily, and everybody rubbed the government's face in the fact that the laws against crypto publishing directly violated the First Amendment, plus Phil had the guts to stand up to them publicly, with good lawyers backing him. This not only had excellent PR value, but got a lot of people interested in crypto. From a more practical standpoint, it was Netscape's decision to include SSL, even with wimpy crypto, that moved the public perception of crypto from "something only spies and paranoids and occasional political activists use" to "of course I use it, how else would I send my credit card number across the Internet without getting ripped off!" Even now most of the public doesn't send much encrypted email (even the cypherpunks don't send huge amounts of encrypted email), but everybody knows you can, and everybody knows you should always use encrypted form for your credit cards and other sensitive personal information, because otherwise Hakk3rZ will steal it, and that's a good start. (Sigh - if you can't get the public to use a term correctly, at least you should exploit the heck out of their misuse :-)

      The real place that cryptography has been left out has been the Voice-over-IP telephony world. The de facto standard H.323 doesn't do it, though some of the newer protocols like SIP and MGCP provide hooks or full mechanisms for it, and most of the proprietary Internet telephony programs don't appear to support it either. This means that we're building an easily wiretapped infrastructure for international calls, and starting to build one for US domestic calls as well (and at least in the UK, wiretapping ISPs is easier legally than wiretapping telephones.) On the other hand, H.323 is somewhat of a lowest-common-denominator protocol, and the newer protocols will probably be adopted because of increased functionality; until then we'll need to get IP telephony services to adopt IPSEC.

      IPSEC is still only marginally ready for prime time, but capabilities and compatibility of free and commercial implementations are improving, and there's substantial business demand pulling them. The automotive industry ANX network jumpstarted it, but the cost advantages of dial internet compared to running your own modem pools are one of the big drivers, and for some industries, the ability to use the internet instead of private frame or ATM networks for corporate traffic is also a big economic win, though that's more dependent on communication patterns.

      I suspect end-to-end encryption for cellphones will be a small niche market for a long time, as opposed to encrypting the airlink from the phone to the cell site. What may change it is the obvious interconnection between voice over IP and cellphones merging into internet telephony to the cellphone. Cellphones already digitize and compress voice, which is one of the hard parts, but cellphones take a telephony-centered view of mobile connectivity which will take some work to merge with the still-evolving mobile IP technology. The obvious first level of integration is gateways between the cellphone carriers and the internet voice carriers, which makes it easy to still charge by the minute for cellphones. In countries that use handiphone service (mostly Asia - it's the "you can use the phone anywhere but we don't switch cells, so you can't move very far" dumb cheap technology), it wouldn't be too hard to integrate a handiphone base station with DSL so anybody could run their own microcell and get their cut of the cellphone charges, which has viral marketing possibilities that are harder to implement in a usable-while-moving true cellular system.

      --

      Bill Stewart
      New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  2. crypto stuff by Signal+11 · · Score: 3

    What I'm waiting for is them to open up restrictions enough to let these guys get their patches added to the main linux kernel tree. I think it's a shame that linux is lagging behind OpenBSD due to our country's legal hangups over crypto. This is good news.. I just hope it's enough.

  3. Re:"Software experts" don't think recursivelly by Pac · · Score: 3

    Yes, I have read Shor's paper and the papaers about quantum secure communication.

    But my point was altogether different. The so-called "software experts" were teorizing about the decryption possibilities of a future computer architecture without taking into account the encryption possibilities of the same architecture.

  4. The devil is (still) in the details by Skapare · · Score: 3
    In a speech before the Citizens Crime Commission of New York last July, FBI Director Louis Freeh warned that encryption systems in the wrong hands were a threat to the nation's security.

    Louis Freeh was never able to show that if the Unite States blocked all its encryption products from export, that this would result in terrorists being unable to get that encryption. His agenda was pure fantasy.

    "A terrorist operating without a lot of sophistication, targeting a hospital, a stock exchange, a power grid, or informational systems upon which we all depend poses all kinds of different, complex but imminent threats," Freeh said. "There is real danger in fantastic technologies that are at the beck and call of fairly unsophisticated operators."

    And these things are entirely possible to no less a degree even with a total ban on all export restrictions. But take a look and his reference to "fairly unsophisticated operators". That description sure sounds to me like it also fits script kiddies. With his logic, we should suspend free speech to stop such crime. Better yet, suspend the whole US Constitution. That is what many in the upper levels of law enforcement actually want.

    Software experts said that although many new encryption systems cannot be broken, their U.S. makers are cooperating with federal law enforcement and intelligence agencies. Somewhere in the future, they said, are so-called quantum computers a billion times more powerful than existing home computers. These would be able to break the most sophisticated encryption systems available today.

    Or, make new encryption systems which would have no hope of ever being broken.

    World Trade Center bomber Ramzi Yousef, for example, used over-the-counter encryption technology in his laptop computer, according to the FBI. It included two encrypted files that it took FBI experts more than a year to decipher, law enforcement officials said. Among his plans was one to blow up 11 U.S. airliners in the Western Pacific in one day.

    If he acquired this technology by means of encryption exported from the USA, then it might give the FBI some level of credibility here. If he did, but could have just as easily acquired it from somewhere else, that credibility is just shot back down. In fact, he was actually in the United States, and could have easily acquired the technology domestically. The only argument the FBI could logically derive from these events is that all encryption must be suppressed by all governments, and a massive world wide search conducted to expunge every bit of it from every corporation and individual on the planet. And we know how easily they could accomplish that. They probably know, too, so I wonder what their real agenda was, other than to just stir up emotions.

    Restrictions on U.S. exports to some others would continue. They include Cuba, Iran, Iraq, North Korea and others considered America's foes.

    It remains to be seen just what level of bureaucracy will be imposed on this export. The article says "sell". Does that mean we don't get to give it away (in reference to what is already legally free)? Just how much will we be required to put people through to let them download strong encryption software? Will we be able to contribute source code to crypto projects located outside the US?

    I suggest that the State Department provide a list of IP addresses which they want download refused for, and no more than that. It should be possible to get the addresses connecting "Cuba, Iran, Iraq, North Korea and others considered America's foes". This is sufficiently practical to manage and can be smoothly automated. Any more than that and I will certainly see it as excessive government interference in the private sector.

    --
    now we need to go OSS in diesel cars
  5. really... by Tiro · · Score: 3
    Sell encryption technology?!

    Who needs to sell encryption technology when we have OpenBSD?

  6. Linux and encryption.. What I want. by Convergence · · Score: 3


    We've all heard of the nastiness with people snooping around our hard drives.. Since automated bootup's are important, I don't think it's practical to require a password JUST to decrypt stuff to start up the machine. Even if users can use encrypted loopback filesystems to encrypt stuff, there are other places where stuff can hide.

    Here's what I'd like for linux:

    Encrypted swap file. It doesn't get cleaned out regularily, there's no easy way TO clean it out, and it's something you can easily miss. As an alternative, clean it on boot and slowly overwrite unused pages. (Say, nuke one free page every X seconds.) Or encrypt and overwrite, to make things harder to backtrace.

    Secure delete. Have the ability to secure-delete files, on a per-file or per-partitian basis. (I'd nominate '/var' for this.) Or, have a way to slowly run through free harddrive space and nuke anything sitting there. Best yet, have both.

    Secure storage of old logfiles. Logfiles can be a goldmine, squid, httpd, mail, process accounting, lastlog, etc. You want to save them around, but you don't want anyone nosey to be able to look at them. How about secure deleting them and then running them through a user-chosen PGP key for storage, or making several different archival backups on different PGP key's. That way, I can keep the last week's logs on my pgp key, and secure-delete them after a week, while keeping the archival logs on a PGP key that isn't even physically located near the computer. (In a bank, or a friends house.)

    Encrypted /tmp. Let someone define a /tmp partitian that isn't intended to survive a reboot. That /tmp may be encrypted with a random key and then reformatted on each reboot. You can make a second /tmp2 which is formatted normally and is kept accross a reboot. This could be hacked with encrypted loopback and mke2fs it on bootup.

    None of these require a non-automatic bootup.

    For semi-important stuff that you don't want people to look at easily (shell history, other history, email), you can store it in an automatically-generated encrypted file. Each file is encrypted with a seperate key. The inode stores the file-key XOR'ed with a user-key, a group-key, a root-key and an 'any-key'. Having a root-key on every file means that the contents can be compromised if root's password is compromised. This isn't much of a problem because any really important files can be in an encrypted partitian. Leaving it out doesn't buy you much either.

    The group-key is stored in /etc/group. The user-key is an XOR between a number sitting in /etc/passwd and the MD5 hash of their password.
    This type of encryption is a good choice for something like ~/.bash_history, or ~/.ssh, or ~/.pgp. The 'any-key' is a the plaintext key, it exists if the file is readable to the public, It also must exist for any encrypted file that's required for bootup. (such file may be phsyically encrypted, but must be logically plaintext). All files are subject to normal access permission, and the above keys are altered appropriately and automatically on a chmod.

    As we still want to retain automatic boot, some files must remain physically unencrypted, or logically unencrypted. (encrypted with a key, but a key that's stored unencrypted on the drive.) log files in /var, for example. There are some reasons to keep all files physically encrypted; it makes it hard to trivially scan the drive for statistically interesting material. The drive superficially appears a morass of encrypted gibberish. :)

    Unless I'm mistaken, the above, or a variant of the above won't prevent automatic booting. Also, it doesn't require anything extra from user-level code and it'll keep even very nosey people away.

    Finally, you have encrypted filesystems. Real encrypted filesystems that are mounted manually by the user. These could be immune from everything but a hardware sniffer, or a root sniffer.

    Personally, I can't wait to see some or all of these.. First priorty for me is encrypted swap file, secure deletion, and secure storeage of old logfiles. There is already a (hackish) implementation of encrypted filesystems. With that, you can hack an encrypted /tmp. The transparently-encrypted filesystem is the most complicated, but would be sweet to have. :)

  7. Re:Fawking Moderators by TheReverand · · Score: 3
    I got an idea, why don't you get a life? You just wish you could have a +1 bonus like us elite uber-posters do. Idiots like you who seem to think that the karma system affords you something outside of this web page.....

    Scene: Linux Expo, Andover Booth, Rob and the gang are playing Diablo 2 on their win2k boxes.

    Rob"Guys, go to tux screensaver here comes some SlashBots!!!"

    All hit their hotkeys. Up comes Joe Slashbot, With a CD full of Slashcode, looking for an autograph.

    Joe"Hey guys, uhh remember me? I uhh, like posted that +5 insigtful comment about why Microsoft will never be as cool as Linux?"

    Rob"Yeah sure right uh huh."

    Joe"Yeah my karma is up over thirty now, and I have the +1 bonus!! Now everyone can see what I right!!

    Rob and company nod and smile, and begin to crack jokes as the Slashbot wanders off. Once he is safely out of range Rob goes back to checking his E*Trade account, and the rest go right back to Diablo 2.

    End Scene

  8. I Would Never Use U.S. Encryption Because... by Sir_Winston · · Score: 3

    There's zero chance that I'd trust the U.S. companies to have not made deals with the NSA/FBI/CIA triad, especially if they've been exporting crypto even before the relaxation of export restrictions. It was common practice for the NSA to send a man around to U.S. crypto vendors hinting that if they'd make a few changes to the code here, or alter the S-Box there, they'd get an export license for their 128-bit etc. product.

    Granted, there are a few noteworthy cases of the U.S. tainting foreign crypto vendors, like the Crypto AG fiasco in which the Swiss(?) firm inserted a back door which allowed the U.S. access to messages encrypted with their very, very expensive hardware crypto devices. But I'd still trust a European vendor over an American one, though these days the important thing is having access to the source code.

    For example, why use a PGP binary provided by Network Associates when you could either download the full-strength PGPi version from overseas, or better yet if you actually know your code you could dload the source and compile it yourself. Getting a binary from an American company just adds one more layer of uncertainty to the mix.

    My favorite product for disk encryption is a perfect example. There are many American companies which offer encryption utilities, but why use one of those when I can download Scramdisk from www.scramdisk.clara.net along with the source code? It isn't GPL, but the source is still available for inspection and for personal use. Scramdisk comes from Britain, whose own crypto regulations are getting insane, but still Britain doesn't have the same long tradition of sabotaging their own domestically produced crypto products, as well as international ones, that the U.S. does.

    Buying U.S. crypto, unless you have access to the source code and the skills to verify it, is just asking for trouble.

    --


    "The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*