Talk:VEST

From Wikipedia, the free encyclopedia

Contents 1 Efficiency in software 2 Bias 3 VEST-8 and VEST-64 4 Latest Changes 5 Outdated Posts

[edit] Efficiency in software

VEST may be designed to be efficient in hardware, but it's still worth mentioning how dire it is in software. It's not unusual for one end of a comms link to be hardware (eg the mobile phone) and the other in software (eg the base station). The base station can afford a few extra cycles to make life easier for the phone hardware designers, but the staggering software cost of this cipher is another thing again. Contrast to Trivium, which does quite nicely in hardware, but manages a very respectable 12 cycles/byte in software. — ciphergoth 10:07, September 5, 2005 (UTC)

Ah, fair enough. — Matt Crypto 10:52, 5 September 2005 (UTC)

[edit] Bias

User:Ruptor writes in a comment:

18:28, September 7, 2005 Ruptor m (→Efficiency - Ciphergoth's comments suggest that he is negatively biased against VEST. Is he an author of some competitive design? Authors did not conjecture anything. I did.)

Actually, the authors do suggest a bitslice implementation would be faster, see section 6.3 of the spec:

Various optimisation techniques such as bit slicing may improve software performance

so I shall revert your edit on that point.

And for the record, I am not the author of a competing design; I have no vested interest besides wanting the best ciphers to flourish. I have negative feelings towards VEST for no other reason than that I've read the spec and I think it's a terrible design.

The software performance is beyond dismal, and there's simply no excuse for it; even if the main focus is good performance in hardware, that can be achieved with an eye to at least half-way respectable performance in software. And designing a family of five ciphers for different gate count tradeoffs is similarly shoddy. Finally, it is unjustifiably complex. Look at AES or any of the better AES candidates, such as Twofish - they offer a number of different implementation tradeoffs, for high or low gate count or software implementation, which all implement the same cipher. This is important because typically, the two communicating ends are not the same - one might be a small handheld device like a phone, while the other might be a base station multiplexing millions of calls.

Closer to the bone, contrast VEST to Trivium, which sadly I have not had time to put together a decent Wikipedia entry for. Trivium is extremely simple, and manages a respectable 12 cycles/byte (ie 3 cycles/bit) in software with a bitslice implementation; I suspect faster is possible but I haven't coded it yet. It admits of low gate count implementations that produce one bit per cycle, or wide implementations that do 64 bits per cycle. And these are all the same cipher - all these disparate implementations can interoperate.

Naturally, NPOV must preside. However, NPOV does not mean that the article should gloss over the cipher's serious shortcomings.

Full disclosure: I have socialized with various eSTREAM authors, but since I'm boosting Trivium here I should say that I have only met one of the authors (Preneel) once and briefly and he would be unlikely to remember who I am. The only other bias I might mention is that I'm aware and think well of VEST author Howard Landman because of his polyamory-related work.

Though I'm laying into VEST here, I don't mean to lay into you. I'm glad you've come onboard and started improving Wikipedia's coverage of crypto! I may bristle a little at the accusation of bias, but actually it's quite understandable given how passionately I'm slagging VEST off. If you don't mind my asking, do you have any biases related to VEST you'd care to disclose - do you know any of the authors?

Thanks again — ciphergoth 20:24, September 7, 2005 (UTC)

The article looks neutral enough to me at present. It gives the relevant facts and speculations about VEST's hardware and software performance, and that it's claimed only to be efficient in hardware. — Matt Crypto 21:38, 7 September 2005 (UTC)

I've only now discovered this page thanks to Matt. I must admit that I didn't notice the authors' claim of potential software speed improvements with bitslicing. It's an obvious thing. I am new to Wikipedia. I don't have a clear understanding of how editing here works. You guys obviously have much more experience than me, whatever your opinions are. Sorry if I stepped on anyone's toes. Ruptor 02:21, 8 September 2005 (UTC)

No problem. Since you asked me about my biases, I hope you don't mind me asking about yours - do you know any of the VEST authors? Thanks! — ciphergoth 09:01, September 12, 2005 (UTC)

[edit] VEST-8 and VEST-64

The VEST paper on the eStream website only mentions three variants: VEST-4, VEST-16, and VEST-32. Where are the details of the other two mentioned here (VEST-8, VEST-64) published? Also, can you refer us to the source by which you learned that Bigeard does not wish to be listed as a submitter? The paper says one thing, but the eStream website says another. — ciphergoth 17:07, 14 September 2005 (UTC)

Bigeard does not wish anything. I was simply informed by the authors that his name is not in the paper as one of the submitters and that it ended up on the web site by mistake, asking me to remove it from the Wikipedia article since I wrote it. Other than that they did not object against anything, only confirmed that a bitsliced implementation performs at speeds comparable to the AES (not the 700 clocks per bit as I measured it, which you may also want to remove from the article as "my own research" that has no other reference). I was also told that an updated clarified submission is in the process with VEST-8 and VEST-64 in it and with a minor bug fix somewhere in the source code. It should be updated on the ECRYPT web site shortly.

I apologise again for my "non-standard" terminology using clocks per bit instead of clocks per byte. It's just a lot easier to convert to gigabits per second like that by simply dividing the clock speed (let's say 1 GHz) by the number of clocks per bit, one operation less to calculate having to divide it by 8 every time. I also apologise for not taking your publications listed on your web site very seriously.

(last comment was Ruptor, 22:53, September 14, 2005)

OK. Since the website and paper contradict each other I have no problem going by the paper. However we should probably temporarily remove the unlisted VEST variants until they are published.

I agree, it's in some ways unfortunate that clocks/byte took off rather than clocks/bit, but there you are.

You're right, we should find a published source for the speed estimates. I believe Bernstein has done some measurement that we could cite. I'm unlikely to have time to look it up for a few days though.

When you say "bitslice", do you mean in the original sense of many instances of the cipher running in parallel, or do you just mean it as a way of optimizing a single instance of the cipher? Good performance for multiple instances in parallel is interesting but not terifically relevant, since in practice the management headache of arranging for a single engine to run all your instances of the cipher in parallel is pretty great.

I'm not sure whether you mean the last sentence as an apology or an insult - if the latter, please read WP:ATTACK. If you want to take part in the field of open crypto research, as it seems you do, I can tell you that it is in general an extremely friendly and welcoming field, which seems to be free of the enmities and petty rivalries that bedevil other scientific fields. I hope that you can embrace that spirit as you join. I would also be interested in learning more about your crypto-related work - you mention an interest in cryptanalysis on your web pages, but you don't mention any specific results. — ciphergoth 06:44, 15 September 2005 (UTC)

Hey, ciphergoth! This is the first reply of yours that I like. Sounds like we are making some positive progress. Maybe one day we'll get to a point where you would even say hello to me. As I said before, I don't mind switching to clocks/byte for wikipedia articles, but I disagree with having to refer to some source of information when something can be easily calculated or measured by anyone. The RDTSC instruction on Intel processors and the %tick register on Sparc processors are very easy to use. Anyone can verify those measurements. The same with statements that let's say Trivium's ASIC performance at 2.5 GHz would be encrypting 160 Gigabit per second. You don't need a separate source of information to take 2.5 and multiply it by 64. Then we can build easily verifiable comparison tables ourselves instead of waiting for Prof. Bernstein to do it for us. I would strongly argue against them being personal research. There's no research in multiplying 1 GHz by 64 bits of output to get an estimated 64 Gbit per second figure to compare one cipher with another. You don't have to explain to me the intricacies of ASIC implementations. If we don't have someone else's figures to refer to, I don't see why we can't measure them ourselves. The approximate maximum achievable clock speed is fairly easy to estimate using opensource ASIC tools. Synthesis of a cipher like Trivium using those tools resulting in a measurement of its approximate maximum clock speed is no personal research and takes very little skill to verify. Even using a calculator to verify the fact that 26! > 2⁸⁰ requires prior training, but you wouldn't demand a source of information for it if you found it in a wikipedia article. You'd just take a calculator and verify it yourself.

When I say "bitslice" I always mean multiple independent parallel instances. Parallel AND/OR/XOR instructions the way they are used in MD5/SHA/Serpent/Trivium are no bitslice, although Wikipedia teaches me now to have a more open mind to accept other people's points of view as viable even though they may be technically incorrect. Bitslice software implementations are as technically relevant as pipelined hardware implementations. All the competitive hardware implementations of the AES are heavily pipelined. Not all applications can benefit from it due to the expensive overhead and unavoidable latency, but we have to compare apples with apples: if someone "cheats" on their hardware performance figures, I don't mind if others "cheat" on their software performance figures the same way. It makes comparing ciphers designed for different environments easier.

I have no interest in attacking anyone here, so no insult intended. I signed up to help by correcting errors in articles and by writing new ones. I am also not interested in publishing anything in the field of open crypto research besides what is already public knowledge and besides some basic sources implementing it correctly. And if you are really interested in learning anything about my crypto research, I suggest e-mailing me your 16-kilobit PGP CKT key.

— Ruptor 03:51, 18 September 2005 (UTC)

The point about hardware pipelining of AES candidates is an interesting one. If you're using CTR mode, the fact that it's pipelined makes almost no difference to the way that you use it. But if you use CBC mode, you have the same management headache as a multiple-instance bitslice mentioned above. Since CTR mode is rapidly becoming the most popular mode, I don't think it counts as a "cheat", so I don't think your comparison is fair. If there's a way to "fast-forward" VEST so that it's generating a later part of the stream, that would increase the usefulness of a bitslice implementation enormously. LEVIATHAN had this ability, but it's sadly rare.

If I send you my zillion-bit public key, how will you verify it's from me? What I'm really interested in knowing about is your contribution to the open research. A link to the appropriate pages on CiteSeer is all I need - thanks! — ciphergoth 06:53, 18 September 2005 (UTC)

[edit] Latest Changes

Ben, can you please refrain from using Wikipedia for publishing original research or marketing texts? You seem to be really attached to Sean's design as if it was your own. It's understandable, but please make sure that all the information you post here is verifiable, and provide links to the sources of information if necessary. Thanks! — Ruptor 08:25, 24 October 2006 (UTC)

PS: I hope you are not going to start reverting my edits inconsiderably.

[edit] Outdated Posts

I have removed a lot of posts from here that were 1) misplaced, 2) my fault sparking those arguments in the first place purely thanks to my initial ignorance of Wikipedia rules and guidelines, and 3) no longer relevant to the page in the light of the latest cipher specification updates. I apologise to everyone I have offended here with my natural rudeness. If anyone finds those posts highly important, feel free to bring them back to life. I won't revert them. — Ruptor 08:25, 24 October 2006 (UTC)

I'd rather the discussion stayed; restored. — ciphergoth 19:14, 24 October 2006 (UTC)

Mind explaining why? — Ruptor 23:46, 24 October 2006 (UTC)