Stories
Slash Boxes
Comments

SoylentNews is people

posted by Woods on Sunday April 20 2014, @11:29AM   Printer-friendly
from the wave-particle-duality dept.

Harvard researchers claim to have developed a switch which can be turned on and off by a single photon.

From the article at PHYS.ORG:

Built from single atoms, the first-of-their-kind switches could one day be networked via fiber optic cables to form the backbone of a "quantum Internet" that allows for perfectly secure communications, said Professor of Physics Mikhail Lukin, who led a team consisting of graduate student Jeff Thompson and post-doctoral fellow Tobias Tiecke to construct the new system. Their research is detailed in a recently published paper in Nature.

"From a technical standpoint, it's a remarkable accomplishment," Lukin said of the new advance. "Conceptually, the idea is very simple push the conventional light switch to its ultimate limit. What we've done here is to use a single atom as a switch that, depending on its state, can open or close the flow of photons, and it can be turned "on" and "off" using a single photon."

Lukin goes on to say that although the switches could be used to build a quantum computer, it's unlikely they will show up in the average desktop computer.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Funny) by wonkey_monkey on Sunday April 20 2014, @11:52AM

    by wonkey_monkey (279) on Sunday April 20 2014, @11:52AM (#33583) Homepage

    Single Photon Quantum Switch

    I've been looking for a new password since Heartbleed. This'll do.

    http://xkcd.com/936/ [xkcd.com]

    --
    systemd is Roko's Basilisk
    • (Score: 2) by bucc5062 on Sunday April 20 2014, @12:34PM

      by bucc5062 (699) on Sunday April 20 2014, @12:34PM (#33586)

      I remember that plate and at the time thought, great, but most password entries don't allow spaces or long passwords. Just for fun I recently tried this with my SN account and what a wonder, a collection of words with spaces and it works. I am try this elsewhere as I go along. It is true, a collection of words does seem easier to remember (for now).

      --
      The more things change, the more they look the same
      • (Score: 5, Interesting) by wonkey_monkey on Sunday April 20 2014, @04:37PM

        by wonkey_monkey (279) on Sunday April 20 2014, @04:37PM (#33638) Homepage

        Have you tried logging in with one (or more) characters missing from the end of your password/phrase?

        --
        systemd is Roko's Basilisk
        • (Score: 2) by edIII on Sunday April 20 2014, @09:48PM

          by edIII (791) on Sunday April 20 2014, @09:48PM (#33733)

          Why would that be a problem? As a programmer I would never perform a trim or truncation against a password value. What would be the value of altering the user input in this case?

          Ideally it should be salted before it goes into a database anyway and I would think that the output of repeatedly hashing the password+salt would result in a value that doesn't need to be truncated.

          Isn't the output from most hashing algorithms restricted to "safe" strings with a limited character set like Base64 that have a specified length? For instance, I thought MD5 (which shouldn't be used for passwords) and SHA-3 all had static bit lengths for their output.

          It should just be a matter of defining the correct length in the database schema and input validation is not required as the output from the hashing algorithms is well understood.

          Unless I am missing something and somebody can correct me here. Or Soylent is running on some really stupid code where the password is not salted. I doubt that is true though with a place as technical as this.

          --
          Technically, lunchtime is at any moment. It's just a wave function.
          • (Score: 2) by evilviper on Sunday April 20 2014, @10:34PM

            by evilviper (1760) on Sunday April 20 2014, @10:34PM (#33751) Homepage Journal

            As a programmer I would never perform a trim or truncation against a password value.

            Yes you would. Otherwise it'll be a potential buffer overflow vector.

            What would be the value of altering the user input in this case?

            Besides the above, nobody said there was "value" in it, just that it happens. Look back at old HTTP-basic-auth and you'll see an 8-character password limit, which just silently discards anything past that. Old Unix systems were similar.

            --
            Hydrogen cyanide is a delicious and necessary part of the human diet.
            • (Score: 2) by edIII on Sunday April 20 2014, @11:09PM

              by edIII (791) on Sunday April 20 2014, @11:09PM (#33767)

              Buffer overflows?

              At this high a level of abstraction it should be treated as a variable length string and passed that way. If variable length strings have buffer overflow attack surfaces then every field on the site has one. AFAIK, I can pass a string of any length I want (large limits) back to the site via GET or POST (preferred).

              While I can understand older systems having issues, newer code bases should allow me to pass a variable length string to the hashing function without causing a buffer overflow. Even with a buffer overflow vector being true, the variable length string can be passed from the client side to the server side without much issue at all. It happens so often that I expect Apache, NGINX, or whatever to have taken care of that issue for me.

              Once the string is at server side, I would be very surprised with a buffer overflow attack being successful. Hashing algorithms generally work on very large files as input just as much as they do on short strings.

              You make me want to go tear apart a hashing algorithm used for salting passwords right now to find out if it does have that problem :)

              --
              Technically, lunchtime is at any moment. It's just a wave function.
              • (Score: 2) by evilviper on Monday April 21 2014, @01:32AM

                by evilviper (1760) on Monday April 21 2014, @01:32AM (#33799) Homepage Journal

                I can pass a string of any length I want (large limits)

                It's large, and longer than anyone would use for a real password, but it's still a field you have to put a limit on. Don't count-out somebody maliciously inserting multiple gigabytes of data into a password field...

                --
                Hydrogen cyanide is a delicious and necessary part of the human diet.
                • (Score: 2) by edIII on Monday April 21 2014, @04:11AM

                  by edIII (791) on Monday April 21 2014, @04:11AM (#33845)

                  I'm not implying that buffer overflows are impossible, but that we shouldn't be forced to perform string truncation at such high levels of abstraction and not to a low amount like 8 chars or even 64 chars.

                  Even then that's pushing too much of the security responsibility for inputs to the browser. I'm looking at this almost purely server side. At server side you could truncate it to 1024 chars and be just fine.

                  My core point is that, assuming the inputs on the hashing algorithm are safe from buffer overflows, we should see no difference with 8 chars or 1024 chars passed. It will still always end up being a 160-512 bit value provided from the standard hashing algorithms being provided password+salt.

                  Password fields should ideally be content agnostic and stored in char(64) fields, with every stored password being exactly 64 chars or whatever the defined output for your hashing algorithm is. If done correctly cryptographically an attacker in possession of millions of stored password shouldn't be able to perform analysis based on length or frequency, but be forced to spend an equal amount of time performing cryptanalysis against each seemingly random set of numbers.

                  Silent truncation on a field that gets a lot of its strength from length seems fairly unwise to me and not best practices. Even the 1024 length seems arbitrary when it gets converted down to char(64) every single time.

                  The buffer overflow is a good observation, I just thought it was strongly mitigated at this point. At least in cryptographic primitives.

                  --
                  Technically, lunchtime is at any moment. It's just a wave function.
  • (Score: 2) by Nerdfest on Sunday April 20 2014, @01:39PM

    by Nerdfest (80) on Sunday April 20 2014, @01:39PM (#33593)

    "it's unlikely they will show up in the average desktop computer" will probably end up sounding like "640K should be enough for anyone" or "there is a world market for maybe five computers".

    Yes, I know the 640K one is not really what was said.

  • (Score: 2) by SuperCharlie on Sunday April 20 2014, @03:52PM

    by SuperCharlie (2939) on Sunday April 20 2014, @03:52PM (#33621)

    Maybe I'm a little optimistic but I think we are due for a game changer technology. We have been building on old technology for a while now, sure we've made it smaller, faster, etc. but its been incremental, not "other" like the difference between whale oil and electricity. I think the quantum realm is the next "other" that will open up possibilities we havent even thought of yet. Exciting times my friends... exciting times.

  • (Score: 5, Informative) by captain normal on Sunday April 20 2014, @04:19PM

    by captain normal (2205) on Sunday April 20 2014, @04:19PM (#33630)
    --
    When life isn't going right, go left.