Re: Using Salsa20 in a new protocol spec



Adam Ierymenko wrote:
On Aug 14, 3:55 pm, MTGAP <mtga...@xxxxxxxxx> wrote:
On Aug 14, 12:49 pm, Tom St Denis <t...@xxxxxxx> wrote:





On Aug 14, 1:42 pm, Adam Ierymenko <adam.ieryme...@xxxxxxxxx> wrote:
I am presently writing a new protocol spec and reference
implementation. Should I consider using Salsa20?
http://cr.yp.to/snuffle.html
http://www.ecrypt.eu.org/stream/salsa20pf.html
It is very fast, simple, easy to implement, portable, and seems to
have gotten good press. However, it is not finalized yet. Anyone
already using it? Is such an algorithm likely to get revised?
What's wrong with AES-CTR for a stream cipher?
Tom
Salsa20 kicks butt. That's what.

AES is much more standardized, of course. So it may be a better
choice. Like they said in Practical Cryptography, if you use AES and
someone breaks it, no one can blame you for using the government
standard.

I'll probably go with Salsa20. It's a private open source project, so
CYA is not an issue.

How do you figure that? If you implement something not approved by the government as "the" standard, then you're going to a donkey barbecue and they're going to chew on your ass.

It's also for protecting a network protocol
against naive DOS attacks and packet spoofing, so if someone finds a
way to break it with a 100000 node cluster in 2 weeks that really
isn't much of an issue either.

Just wondering if there were any potential issues with it being not
set in stone yet, but from what I've read it's pretty much the
finalist and isn't going to change. I did some more searching and
found that it was already in the Linux kernel too.

The big feature that attracts me to it is simplicity and endian-
neutrality, which means I don't need to worry about endian-ness for
portability. The fact that it's a stream cipher makes it easier to
code with too.
.



Relevant Pages

  • Re: Need help on modifying and assembly of a small program!
    ... care for "international support" at the moment...BUT will you care _LATER_? ... make your keyboard driver use "keymaps" or something (which simply ... that there's a kind of "standard" for typing English with their Cyrillic ... This is the "portability" of the OS source ...
    (alt.lang.asm)
  • Re: removing a loop cause it to go at half the speed?
    ... The concepts are also useful because they are well defined by the same standard that defined the C language. ... If the standard says it is undefined behaviour then even if your implementation defines it you know that you will have to check whether it is documented for *every* system you want to use it on in the future, and you may well come across a system which leaves it completely undefined and possibly even causes random behaviour. ... or you will have on some other platform. ... Portability is not always easy or possible, but the starting point is knowing what the C standard guarantees and what it doesn't. ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... See the C Standard. ... >> tolower() is implemented. ... >> platform, without even having to know which character set is used on that ... is, however, an error in portability for me to *call* that macro. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Storgae durations
    ... standard you referred to is no longer current. ... advocating C99 and saying that C90 is obsolete, ... Then you are in no position to make an argument about C99's portability ... there are implementations for C99 that target those platforms. ...
    (comp.lang.c)
  • Re: The illusion of "portability"
    ... Portability for them means the least common denominator. ... accepted and debugged the standard in use was. ... If I write to the C99 ... Other than the lack of a prototype for printf(), ...
    (comp.lang.c)