Hacker News Reader

Comment by kqr2 | Hacker News Reader

From the comment section, Mike Linksvayer quotes:

http://www.kanai.net/weblog/archive/2007/01/26/00h53m55s

  Why was SEED developed in the first place?

  South Korean legislation did not allow 40 bit encryption for
  online transactions (and Bill Clinton did not allow for the
  export of 128 bit encryption until December 1999) and the 
  demand for 128 bit encryption was so great that the South 
  Korean government funded (via the Korean Information 
  Security Agency) a block cipher called SEED.

View on HN

The web is still recovering from the US ban on encryption. It's ridiculous.

That's my blog. Happy to answer questions if anyone has any. Basically the situation hasn't changed since 2007, sad to say.

Longer-term, one of the few rays of light for S. Korea is the work that is just starting around providing JS-based cypto in the browser (i.e. not via a plugin.)

http://www.w3.org/2012/webcrypto/

http://domcrypt.org/

If you are interested in helping to get S. Korea off Active-X, your help in getting WebCrypto developed and standardized is probably the best thing you can do (as a developer.)

(I work for Mozilla but not on DOMCrypt.)

Why wouldn't a stand-alone application or device serve this purpose much better? The requirement of a confirmation code generated by a simple piece of electronics not more sophisticated than a pocket calculator or a mobile app could side-step this completely.

I would say it changed a lot, especially after iPhone was released in Korea. By laws, government websites now have to support multiple browsers and laws, and several banks now offer "Open Banking" which supports Mac and Linux.

The problem is that the law still requires these websites to use "firewall" and "anti-keylogger", so they just implemented those programs for Mac and Linux in NSAPI form. This is still far from "web standard", but at least they are trying. =(

NSAPI is no different than Active-X. It is not solving the central problem of requiring plugins vs. ssl.

Exactly. I am hoping, one day they'd realize it doesn't make sense to waste money writing plug ins for each browser and platform, and just use the standard, but...

How do you enforce a ban on encryption? Weren't the algorithms mostly open source by 1999? Or why aren't other countries like Japan & Canada in the same position?

The browser (which implements the encryption) would be banned. I remember I could choose between US only version (128-bit encryption) and international version when I download Netscape. Of course I could just download the US version, but Korean government couldn't enforce banks to use 128-bit officially. (not to mention IE bundled with Korean Windows would not have supported it.)

See http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_U...

> How do you enforce a ban on encryption?

By classifying it as a munition and using those laws. Which don't apply to books like "Applied Cryptography" by Bruce Schneier, due to the First Amendment. Even if they have source code printed in their appendices.

Oh, you mean effectively? Uh... I suppose we'll have to get back to you on that.

> How do you enforce a ban on encryption?
By classifying it as a munition...

Oh, you mean effectively? Uh...

Back in the day, someone printed up a T-shirt that had a 4-line Perl script that did RSA and so was a munition. (Later reduced to 3 lines.) There was a barcode that contained the bits for the script, which you could use to automatically read the program into a properly configured computer, so the T-Shirt was indeed a munition under those regulations.

The ban wasn't on the algorithms, it was on products using them. You could write a book describing RC4 or Blowfish and ship it anywhere, but you couldn't ship a web browser that implemented it outside the US until 1996.

Reply on news.ycombinator.com