The disadvantage is carrying around a very large digital key (which could easily fit on one of those USB memory key fobs).
If this system is anything like a OTP, this means that the "very large digital key" would be exactly the same size as the data you're trying to protect... And if a USB memory key fob is large enough to store this "very large digital key", and safe enough to store the key to decrypting the important data you're trying to protect...
Why not just store the important data on the USB memory key fob..
If we're already operating under the assumption that it's big enough and safe enough for the key, then storing the original data in the same place must also be secure. And, of course.. if this isn't secure, well.. then it's not a very smart place to store the key, now is it?
This a catch-22 type situation with creating an actual usable implementation of a OTP.. the key is the same size as the data you're trying to protect.. If you have a safe place to store the key, might as well just store the data there..(and if you have a safe way to communicate the key, you might as well just communicate the data)
And of course, the fact that the key is the same size as the data being protected, is what provides the OTP with it's unconditional security.. If the key isn't the same size as the data being protected.. well, then it must repeat, or use a key scheduler or something that would weaken the cipher towards cryptanalysis...
If this new algorithm really does have the unconditional security of a OTP, it probably has the same usability issues of a OTP... And if it doesn't.. it's probably not as secure as a OTP...
Slashdot Mirror
If this system is anything like a OTP, this means that the "very large digital key" would be exactly the same size as the data you're trying to protect... And if a USB memory key fob is large enough to store this "very large digital key", and safe enough to store the key to decrypting the important data you're trying to protect... Why not just store the important data on the USB memory key fob..
If we're already operating under the assumption that it's big enough and safe enough for the key, then storing the original data in the same place must also be secure. And, of course.. if this isn't secure, well.. then it's not a very smart place to store the key, now is it?
This a catch-22 type situation with creating an actual usable implementation of a OTP.. the key is the same size as the data you're trying to protect.. If you have a safe place to store the key, might as well just store the data there..(and if you have a safe way to communicate the key, you might as well just communicate the data)
And of course, the fact that the key is the same size as the data being protected, is what provides the OTP with it's unconditional security.. If the key isn't the same size as the data being protected.. well, then it must repeat, or use a key scheduler or something that would weaken the cipher towards cryptanalysis...
If this new algorithm really does have the unconditional security of a OTP, it probably has the same usability issues of a OTP... And if it doesn't.. it's probably not as secure as a OTP...