Re: VMPC

On Thu, 29 Mar 2007 02:10:49 GMT, "Joseph Ashwood" <ashwood@xxxxxxx>
wrote:


<fortune.bruce@xxxxxxxxx> wrote in message
news:1175116609.263881.247390@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 26, 1:18 pm, "Wei Dai" <use...@xxxxxxxxxx> wrote:
"Bartosz Wójcik" <antis...@xxxxxxxxxxx> wrote in message

news:7knk5cdpbqld$.6zptv4ujnor.dlg@xxxxxxxxxxxxx

What do you think about VMPC encryption?

It is not a substitute for AES. But it is a wicked fast streaming
algorithm that may have use.

It is interestingly simple and elegant, like RC4.

Actually it is generally uninteresting, and poorly designed, strangely again
very much like RC4, although at least RC4 lasted a bit before it was badly
broken.


VMPC isn't very secure.
Seehttp://www.it.lth.se/movax/Publications/2005/vmpc.pdf.

It may not be very secure, but it may be secure enough.

This article talks about a distinguisher of VMPC from random after
observing 2^54 output bytes of data.

And after that everyone stopped bothering, it is broken, attacks don't get
worse.

Yes. Ideally there is no way to distinguish any amount of data from
random. But if that number gets high enough, what is the downside
other than having a "feeling" about it?

The fact that even the most basic statistics say that it is insecure, which
of course means, it is insecure.

Yeah... I know... it shows a bias. But how much and so what? After
18,014,398,509,481,984 bytes

Consider the margin a perfect 128-bit block cipher in CTR mode shows a bias
at 16*2^64 (295147905179352825856) bytes, making the security of VMPC
0.006103515625% as strong. This makes VMPCs strength compared to even a
semi-ideal cipher a rounding error.

RC4, while it has its issues has a similar distinguisher after
observing 2^30 output bytes of data, and it is still in use for now
and the near foreseeable future and is secure at 128-bit when used
correctly.

To rephrase "Another cipher that performs this badly is still in use, so I'm
going to throw a tantrum about it" such arguments are a pointless waste of
time.

[snipped all the stuff that has absolutely nothing to do with the
discussion]

The distinguisher for VMPC comes after 18,014,398,509,481,984 bytes of
data which is > 18 petabytes

And is 0.006103515625% of what it should be to be considered secure.

Now, I can be fairly sure here... that no system, properly designed,
chews through 18 petabytes of data before it re-keys.

And you would be wrong.

I don't know of
any SAN or NAS installations that even support that much hard drive
space at this time.

You'd once again be wrong, at this point almost all SAN systems support
vastly larger spaces, and the NAS heads associated with them can address it.
In fact, the standard NTFS system that ships with Windows since it was added
in a service pack for NT 4 supports up to 67108864 petabytes.

So there are no real-world application where you can even get close to
approaching the distinguisher as far as I can tell.

Then you need information newer than a decade old.

And in a well
designed system, you would never send that much data before re-keying
anyway.

Arguable, but generally not a certainty.

So, [...] other than a possible distinguisher after a solid 18
petabytes of data have been observed (something as an attacker you
will never get to see, BTW), where does the weakness come from?

That's like asking "So other than it falling down around you, why are you
dissatisfied with the house?"

I admit, I am trying to get this discussed, as when distinguishers get
large enough, it becomes harder to see why this is a real-world
problem.

Because the distinguisher is already far too strong to be considered "large
enough."

VMPC is and should be considered horribly broken, attempting to discuss it
in any other terms is not worth the trouble. There are much faster
algorithms, there are more analyzed algorithms, there are more useful
algorithms, there are algorithms that are all of these, VMPC needs to be
left out to pasture.
Joe


The password is "overkill".
.

Relevant Pages

  • VMPC free
    ... "Policy of using VMPC" has been retracted from the VMPC website ... It is now openly stated at the website that the algorithms from the ... "VMPC Data Security") and in the Polish edition of IDG's COMPUTERWORLD ...
    (sci.crypt)
  • Release of VMPC Data Security in English
    ... VMPC Data Security ... messages using the VMPC family of algorithms (VMPC Stream Cipher, ... a substitute for on-the-fly encryption apps, ... High stress is put on the quality of the keys used. ...
    (sci.crypt)
  • Re: VMPC
    ... It may not be very secure, but it may be secure enough. ... This article talks about a distinguisher of VMPC from random after ... chews through 18 petabytes of data before it re-keys. ... algorithms, there are more analyzed algorithms, there are more useful ...
    (sci.crypt)
  • Re: Unbreakable Encryption - Scenarios - What encryption method would be best?
    ... > I will be giving a presentation on VMPC and Tail-MAC in the Polish ... for the following reasons. ... will result in not just the plaintext but every possible message of ...
    (sci.crypt)
  • Re: Encrypting one line
    ... A correctly implemented one time pad is proveably secure. ... of algorithms which fall into the category commonly called "snake oil" ... that there is almost never any reason to use anything else. ...
    (borland.public.delphi.language.objectpascal)