Ah, I saw this when it was released. Essentially, Sᴘʀɪᴛᴢ is a polished RC4 with knobs on. Two big things to point out:
Firstly, security: "Further cryptanalytic review is recommended before this cipher is used in critical applications." I echo that. Have fun cryptanalysing it by all means, but please don't use it. Many already have deep concerns about RC4, and I know I wouldn't feel too comfortable with anything particularly RC4-like, because it's not clear to me yet how pending public results on RC4, or unpublished "cryptanalytic breakthroughs" from Nation State Adversaries (cough) may or may not read on ciphers with a closely similar design. Doesn't inspire confidence.
Secondly, speed. Sᴘʀɪᴛᴢ is not winning any speed contests; in fact, it's pretty much coming in dead last. Looking at cycles/byte (lower is better), in generating sustained keystreams, which is the kindest I can be to it, Sᴘʀɪᴛᴢ clunks along at 24 cycles/byte on their Macbook Air's Core i5, which I think is an Ivy Bridge? For reference, taking the eBACS benchmark results from SUPERCOP, the modern stream cipher CʜᴀCʜᴀ20 runs on an broadly-equivalent processor (h9ivy) at 2.75 cycles/byte—nearly 10 times faster than Sᴘʀɪᴛᴢ! Ouch.http://bench.cr.yp.to/results-stream.html - actually even AES-256, in software, is faster at encryption. From the paper, I also think it's slower at hashing than SHA-512 or any of the SHA-3 finalists.
While the authors note that theirs isn't a particularly optimised implementation right now, I unfortunately don't think there's too much scope for improvement, because what it shares with RC4 are the characteristics that bottleneck performance - if you're code-golfing for minimum code size, fine, but for speed optimisation it shares the same 8-bit-oriented structure with a huge state (bye-bye hardware implementation) and pipeline stalls due to iterative dependencies. This overall design pattern may have made some sense when RC4 was designed, for an 8-bit CPU with no cache, but not so much now - they acknowledge this in the paper and in fact suggest "other word-oriented architectures may be a better choice than the byte-oriented RC4/Spritz style". I agree.
Should you use it, at all? Oh heavens, no. I see nothing to recommend it whatsoever. I do think it's kind of cute though. Made me smile.
Firstly, security: "Further cryptanalytic review is recommended before this cipher is used in critical applications." I echo that. Have fun cryptanalysing it by all means, but please don't use it. Many already have deep concerns about RC4, and I know I wouldn't feel too comfortable with anything particularly RC4-like, because it's not clear to me yet how pending public results on RC4, or unpublished "cryptanalytic breakthroughs" from Nation State Adversaries (cough) may or may not read on ciphers with a closely similar design. Doesn't inspire confidence.
Secondly, speed. Sᴘʀɪᴛᴢ is not winning any speed contests; in fact, it's pretty much coming in dead last. Looking at cycles/byte (lower is better), in generating sustained keystreams, which is the kindest I can be to it, Sᴘʀɪᴛᴢ clunks along at 24 cycles/byte on their Macbook Air's Core i5, which I think is an Ivy Bridge? For reference, taking the eBACS benchmark results from SUPERCOP, the modern stream cipher CʜᴀCʜᴀ20 runs on an broadly-equivalent processor (h9ivy) at 2.75 cycles/byte—nearly 10 times faster than Sᴘʀɪᴛᴢ! Ouch. http://bench.cr.yp.to/results-stream.html - actually even AES-256, in software, is faster at encryption. From the paper, I also think it's slower at hashing than SHA-512 or any of the SHA-3 finalists.
While the authors note that theirs isn't a particularly optimised implementation right now, I unfortunately don't think there's too much scope for improvement, because what it shares with RC4 are the characteristics that bottleneck performance - if you're code-golfing for minimum code size, fine, but for speed optimisation it shares the same 8-bit-oriented structure with a huge state (bye-bye hardware implementation) and pipeline stalls due to iterative dependencies. This overall design pattern may have made some sense when RC4 was designed, for an 8-bit CPU with no cache, but not so much now - they acknowledge this in the paper and in fact suggest "other word-oriented architectures may be a better choice than the byte-oriented RC4/Spritz style". I agree.
Should you use it, at all? Oh heavens, no. I see nothing to recommend it whatsoever. I do think it's kind of cute though. Made me smile.