User talk:Joachim Strombergson
From Wikipedia, the free encyclopedia
[edit] Hi from Matt
Hi, thanks very much for writing the entry for Snow! I've renamed it in line with the more normal convention and tweaked it a bit, but otherwise it looks good, cheers! — Matt Crypto 16:40, 21 February 2006 (UTC)
(I've replied at User_talk:Matt_Crypto#Message_from_Joachim_Strombergson). — Matt Crypto 10:33, 22 February 2006 (UTC)
Hi, thanks for your work on eSTREAM. Interesting choice of focus candidates they made... — ciphergoth 17:34, 28 March 2006 (UTC)
Thanks! Yep, I agree some choices were suprising - actually I find quite a lot of things about eSTREAM to be surprising. Things like:
- The large number of Profile 2 and 2A candidates. I assumed most would be in 1 and 1A.
- That benchmarking has been done against Snow. (Nice though, but surprising).
- Some candidates are written off and then still a focus candidate. Grain in particular.
Phelix and Salsa20 was no big surprises. I like Py, but Trivium is a really weird cipher. And I'm not sure LFSRs connected in a circle will remove the problems with pure LFSR based ciphers. It scales nicely and is really tiny in HW though.
- I like Trivium a lot. Have you read the detailed paper justifying it? I think we can be pretty confident that the sorts of attacks that break most LFSR-based ciphers will not work on it. I know that a lot of people are trying to break it. I'm not so keen on Py
- I also think that eSTREAM erred in their definitions of profiles 1 and 2. Why should efficiency in hardware mean a small key? What if you want a cipher efficient in hardware and software? Trivium is one of the most efficient in software too... — ciphergoth
I agree (once again). Since I work with the development of security solutions for embedded systems I take pride in providing just as good security for these systems as for PC/Admin type of systems. There are memory issues which renders using RSA-style keys with 2048 bits more cumbersome in an embedded environment, and I would therefore liek to use ECC instead - too bad it's a patent minefield. Also I'm not so keen on algorithms that uses big tables/S-boxes - both for the memory needs but also for side-channel attack problems. I just added some more about HC-256 a cipher which is fast but needs large amounts of memory and have a setup time that is bizarre. Joachim Strombergson
- You can do ECC without straying into the patent mindfield - look at the choices some of the free software ECC systems have made. HC-256 is a bit of a niche application - it has such a long setup time that you have to be encrypting in huge bulk before it's useful, and you have to need really high confidence in security and great speed in bulk. But it's interesting nonetheless. After FSE 2006 myself and Hongjun (and Souradyuti Paul) all tried to learn to ski, with pretty dismal results! — ciphergoth 13:00, 29 March 2006 (UTC)
Could you have a look at my proposal in Talk:ESTREAM and see if it makes sense to you? Thanks! — ciphergoth 08:36, 6 April 2006 (UTC)