Talk:Trivium (cipher)

Questions

Where does it say that Trivium is not patented? I cannot find a reference to it in any documents? Does ciphergoth have access to some undisclosed statements by the authors? In any case, since the content must be verifiable, it needs clarification. There is no patent statement in the Trivium specification or on the web site. Ruptor 23:56, 22 January 2006 (UTC)

Deleted Picture

Why did the picture get deleted? Ruptor 16:32, 3 October 2005 (UTC)

It was listed as having copyright problems, because there wasn't evidence provided that it was in the public domain (as it was tagged). — Matt Crypto 16:40, 3 October 2005 (UTC)

The image was deleted as a copyright violation, after being tagged on Sept. 18 by User:Ciphergoth and listed on WP:CP. (here is the deletion log). Since you (Ruptor) were the uploader you should have recieved a note of the copyvio listing, looks like you didn't get notified (sorry about that).

The image was initially tagged as PD. Permission from the copyright holder needs to be documented and verified (since it's previously published material). If you are the image's creator I can help you do this (let me know). --Duk 17:00, 3 October 2005 (UTC)

I emailed de Canniere asking for permission to use the image some time back, but sadly received no reply. I couldn't find anything in the paper or in the eSTREAM rules that gave us permission to use the picture. I commented on the picture a long time ago asking about copyright problems, but got no reply. It's a shame, because it's a nice picture for a good cipher, and well created too. — ciphergoth 17:20, 3 October 2005 (UTC)

de Canniere has since given permission, so I was able to re-add the picture. — ciphergoth 10:04, 17 March 2006 (UTC)

My recent edit

I've just finished a major edit. I've removed and rearranged some material introduced in the preceding edit. Several points arise.

• The ASIC performance estimates appear to be original research. I've substituted the author's gate count and bits per clock estimates.
• NLPFSR appears to be new terminology invented by the VEST authors. Unless and until it becomes general currency in the crypto community we should not use it here.
• The paper doesn't mention FPGAs or ASICs.
• cycles/byte is standard, not cycles/bit.
• I've restored mention of bitslicing, why was it removed?
• The "Security" section appears to have been written to try and make Trivium look bad! It is not an "experimental design", it is in an experimental stage, which is true of all eSTREAM proposals since they are all new.

— ciphergoth 04:00, 14 September 2005 (UTC)

Ok, let me clarify a few things...

• Since I already wrote to you about NLPFSR/PNLFSR, I won't repeat it here.
• The paper may not be mentioning FPGA or ASIC directly, but the design clearly targets it, hence it's reasonable to demonstrate its performance on those platforms. We have a page on RC4 here, but has anyone seen its specification??? I thought Wikipedia was a collaborative effort where everyone chips in. I've just read the NOR page and I understand now why it's not welcome, even though such performance figures may be correct. Although I completely disagree in this case that such an estimate should be called original research. It's a simple formula: 2.5 GHz * 64 bit per clock = 160 Gigabit per second. It's a trivial calculation. But if it's a huge issue, I don't mind.
• There's no "standard" on cycles/clocks/rounds per byte/bit/block as such, but I don't mind either way.
• Bitslicing has nothing to do with a parallelised implementation executing Trivium's feedback function on multiple state bits in parallel. Bitslicing is a process of executing multiple independent cipher instances in parallel. A bitsliced implementation of Trivium would have 288 32-bit registers storing 32 independent internal states. With all due respect, please slow down on reverting others' edits and study the subject matter a bit, and in this particular case I suggest that you fix it yourself. I tried fixing it for you to avoid misleading the readers and to help you not embarrass yourself by showing your ignorance. Your negative attitude towards me is very discouraging and I don't feel like correcting you anymore not for yours not for anyone's sake.
• I apologise for wording the "experimental stage" incorrectly as "experimental design". My bad. I had no intention to make anyone's work look good or bad. Joan Daemen called his Mosquito an experimental design, so it got stuck in my mind as a general term for such ciphers. Some of the ciphers submitted to the eSTREAM are not in the experimental stage, are not experimental designs, and are not new. Take Rabbit and NLS for instance. And that's besides the fact that calling every newly released design being in experimental stage is by all means incorrect. Ed Dawson's Dragon is new, but it's not an experimental design and it is not in experimental stage. There's nothing negative in mentioning it and that's exactly why the authors themselves did not find it embarrassing to put it in their cipher specification.

Ruptor 10:58, 14 September 2005 (UTC)

PS: I am new to Wikipedia and I'm only now learning how to word articles correctly so that they conform to the NPOV and other policies. Please don't take me wrong when I describe certain subjects in a single-sided way. For instance, Non-Linear Feedback Shift Registers with Parallel Feedback do need a page. It's not something that's new and I'm sure a lot of people out there interested in cryptology would want to know what they are and how they work (by the way, Rabbit and Dragon are also both PNLFSRs, but the authors stress the fact that their NLFSRs are word-based instead). I'm also gonna e-mail the VEST authors congratulating them on being the "inventors" of parallel feedback in NLFSRs thanks to you. :)

Ruptor 11:08, 14 September 2005 (UTC)

It's not clear to me that the design targets FPGA/ASIC implementation more than other hardware implementations. If you see ways in which it is especially well suited to them I hope you will inform the authors!

I had forgotten about Rabbit - that does have a slightly longer pedigree than most of the other candidates. Thanks for the reminder! Nonetheless, in the open literature stream cipher design has long been block cipher design's impoverished younger brother, and there are still no stream ciphers in which we have quite the same confidence as AES.

I think you've slightly mistaken my point - it is not that parallel, non-linear shift registers are a new idea in crypto, but that the term NLFPSR is not in widespread use. If the term takes off, then it will be appropriate for Wikipedia to have an article about it.

You are correct that this was the origin of the term "bitslicing", in Eli Biham's groundbreaking bitslice implementation of DES, but in modern usage the term is also applied to implementation techniques targeting a single instance of a cipher. See for example the paper on Anderson and Biham's AES candidate Serpent. Since Biham invented the term, it would be difficult to make a case that his use of it is incorrect. I'm not sure why you're still assuming that I'm unfamiliar with the subject matter even after I've drawn your attention to my publications in the field. In any case, I have not used "ignorant" or any other insulting term about you and I hope you can be persuaded to show me similar courtesy.

— ciphergoth 14:30, 14 September 2005 (UTC)

Oops, I forgot to cover cycles/byte or cycles/bit. It's my experience that the former is overwhelmingly preferred in modern cryptographic literature on software performance. That's confirmed by a Citeseer search: "cycles/byte" finds five papers, four on cryptography, while "cycles/bit" finds no cryptographic papers that use this construction. Papers by Schneier, Daemen, Clapp all use "cycles/byte". I am unaware, for example, of any paper appearing in FSE that uses cycles/bit, but perhaps you can correct me on this point.

The discussion on NLFPSR is covered in User_Talk:ciphergoth. — ciphergoth 16:44, 14 September 2005 (UTC)

For the record, I asked User:Ruptor for an apology for referring to my use of the term "bitslicing" as ignorance; he deleted the discussion from his Talk page [1]. I asked him not to delete discussions from his Talk page, and he deleted that too [2]. — ciphergoth 13:59, 16 February 2006 (UTC)

Bernstein's recommendation on key length

This article (along with other eStream cipher articles) says: The Trivium specifications do not support the use of keys at least twice the security rating of the cipher to prevent parallel brute-force attacks as recommend by Daniel J. Bernstein in his paper "Understanding Brute Force"   Looking through the paper, I do not see this recommendation. The paper does recommend using key lengths longer than the security level, but does not recommend "at least twice the security rating" anywhere that I've found. Can somebody please point me to where in the paper this is said? —Preceding unsigned comment added by Astgtciv (talk • contribs) 01:25, 7 October 2007 (UTC)

Removing the Pasalic attack

I've taken out all mention of the Pasalic attack. I don't think a claim of an attack becomes notable enough to discuss in a Wikipedia article until there's some sort of independent confirmation that it holds water - eg being accepted in a peer-reviewed journal or conference, or being acknowledged by the author of the cipher or some other third party. I also have good reason to believe it doesn't work, but obviously in order for my opinion about this to carry any weight I'd have to write about it somewhere other than Wikipedia so I could reference it here :-) and the standard should be "not notable unless we have a reason to consider it notable", not the reverse. — ciphergoth 13:52, 28 November 2008 (UTC)