Phillip Rogaway

The next few lines are: > It is the user’s obligation to ensure that nonces don’t repeat within a session. In settings where this is infeasible, OCB should not be used. But earlier in that section we have: > […] The nonce doesn’t have to be random or secret or unpredictable. It does have to be something new with each message you encrypt. A counter value will work for a nonce, and that is what is recommended. […] * https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce So given that GCM uses a counter ("C"), and a counter is recommended for OCB, wouldn't it be simple enough to get the equivalent (?) security more efficiently?

Postman's Five Things We Need to Know About Technological Change is a great quick read: https://www.cs.ucdavis.edu/~rogaway/classes/188/materials/postman.pdf

OCB3 also allows associated data (AD). Rogaway's faq[1] describes the history of the versions. OCB1 didn't have AD, OCB2 tried to fix that but was less efficient. OCB3 is the final version of OCB, and is a proper AEAD cipher. After OCB3 was created OCB2 was broken, but OCB1 and OCB3 remain secure. OCB3 is provably secure, and at least 2x as fast as GCM without hardware acceleration. In theory it'd be faster with hardware acceleration, but that's only likely in an FPGA or ASIC implementation since GCM is fast enough and accelerated in modern CPUs. Intel & AMD aren't going to spend the die area on OCB. I like OCB, it's an elegant construction, but I'm more likely to use and recommend GCM because GCM is good enough and allows much easier interop since it's more widely used. Since AEGIS is nicer as a high-performance cipher system, and Ascon is better for constrained systems OCB doesn't really have a niche where it's the best choice. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm

Xbox One/Series has Dev Mode, but that's only for UWP apps which have severe resource restrictions. If you want to use the Dedicated partition you need a devkit. The reasons why consoles lock down developer access so hard is because those interfaces are also very useful for piracy. On iOS, because you can get access to developer tools, you can use AltStore to sign arbitrary binaries with your own dev key[0]. Apple may have said "sideloading is a cybercriminal's best friend", but what they meant is "you're all going to steal iOS apps if we let the general public install software without DRM"[1]. The old Microsoft "Darknet" paper[3] built up a sort of theory of piracy, which I still find useful to invoke here. In the paper, they break the piracy ecosystem down into five pieces: 1. Rippers, who pirate new works and make them available 2/5. Seeders, who transmit new works across the network[4] 3. Players that are capable of rendering creative works 4. Indexes that provide information as to where pirated works can be found To stop piracy, you need to block at least one of these steps. For a variety of reasons, legal action against any of these actors is difficult. Players and indexes are identifiable, meaning we can sue them, but they have legitimate, non-pirate-y uses. Rippers and seeders are hard to conclusively identify, making them impossible to sue. Of course, when people using the power of the state cannot identify criminals, they revert to collective punishment - or…

Mosh would be more widely available, outside of just this 'reference implementation', if it did not use patent encumbered OCB crypto. Phillip Rogaway holds patents relevant to OCB. See the following for his patent grant: http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm I think this is the primary reason why there are still no alternative clients. And specifically, no good Mobile clients. The reliance on OCB is unfortunate. I wish the Mosh developers would introduce multiple cipher schemes so that people can move away from OCB. Unfortunately the protocol is also pretty poorly designed, with no easy backward compatible way to do this. For example, when a client starts a session, the server prints "MOSH CONNECT 60001 sdmDrHqo8DBdpKxtAFAUyw" where the last part is the OCB key. It should have been prefixed with the ciper type for extensibility, but it is not. So this would need a backward incompatible redesign to get it going.

https://www.cs.ucdavis.edu/~rogaway/papers/thorp.pdf (Not that this is the only solution but that it motivates the problem of why you can't just naively apply AES to the problem).

From the OCB FAQ[1]: >What happens if you repeat the nonce? You’re going to mess up authenticity for all future messages, and you’re going to mess up privacy for the messages that use the repeated nonce. The loss of privacy on OCB nonce reuse is not as severe. It would be more or less the same as with ECB mode. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm

Those interested in this topic might also find a couple other papers by Phil interesting: 1. Practice-Oriented Provable Security and the Social Construction of Cryptography: https://www.cs.ucdavis.edu/~rogaway/papers/cc.pdf 2. An Obsession with Definitions (Section 5): https://books.google.com/books?id=SwOkDwAAQBAJ&lpg=PA18&ots=bM…

AES and DES are not groups. See eg https://www.cs.ucdavis.edu/~rogaway/classes/227/winter09/des-is-not-a-…

Oh. I see what's going on, and I was wrong about this. US7949129B2 expired because he didn't pay the patent fees. US8321675B2 claims priority to a patent from 2001. Claiming priority is a way to broaden an existing patent by saying “it's this, but improved”; however, this also means inheriting the expiry date of the patent claiming priority to. So yeah, that one's expiring next year already. Holy cow, thanks for making me check. Another, related patent that he notes in the FAQ[1] is 8,107,620, which won't expire until 2029 unless IBM forgets to pay patent fees. Hard to tell if it really applies to OCB3 though. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil

One license offered for Phil Rogaway's OCB block-cipher mode explicitly prohibits military use. (although, as I read it, the military could use still open source implementations under the other license) http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

These guys join a chorus of academic voices calling for the same. We've seen similar statements from Professors Rogaway and Green in the past few weeks on HN. I think we need a legal solution, but if the tech community refuses to participate in corrupting the technology, it puts the spooks in a worse position. I'd sign a pledge saying I will never work on any apparatus (software, data centers, anything at all) that are used for mass surveillance. That's pretty easy for me to do though... the money government throws at some companies and people for this work is more tempting than the One Ring. http://www.cs.ucdavis.edu/~rogaway/politics/surveillance.pdf http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to… More like this couldn't hurt.

You, too, can help spy on everyone, infringe on human rights, and help with corporate espionage! Be part of something big. Be part of the surveillance state. The future is here. http://www.cs.ucdavis.edu/~rogaway/politics/surveillance.pdf

He's one of those people who's name you can't avoid repeatedly tripping over. I took UC Davis's graduate Intro to Cryptography class from him. It was fun to see how much of crypto history he has been involved with. Interestingly (given the subject matter of this post) he is also well known on campus for teaching a very good Technology Ethics class. (Sample material here.[1]) [1]: http://www.cs.ucdavis.edu/~rogaway/classes/

http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments… If you could provide some more information on responses, perhaps emails dismissing it, I think we can figure out what went wrong.

I wrote this a a few months back: https://github.com/ryancdotorg/libtprpg (do note the disclaimer in the README) It's particularly good for blackjack using multiple decks (that implementation should be able to generate all possible permutations of up to four decks, not that the universe will exist long enough to do it) because it requires no computation ahead of time, only when cards are dealt. I got the idea from this article: http://blog.notdot.net/2007/9/Damn-Cool-Algorithms-Part-2-Secure-permu… see also http://www.cs.ucdavis.edu/~rogaway/papers/subset.pdf

Surprised OP didn't mention OCB which has advantages over his suggestions: http://en.wikipedia.org/wiki/OCB_mode http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#what-is-ocb

I disagree with the premise of your question. I think the overlap is larger than it looks like on the surface. I have come to believe that you cannot do solid secure protocol design without a firm grasp of the basics of encryption schemes. You don't need to be a full fledged cryptographer, but to quote Phil Rogaway, "Reading [Schneier] does not qualify one to do cryptographic design." [1]. In fact, the context in which he wrote "Problems with Proposed IP Cryptography"[1] is a perfect evidence of this: IETF committee designing IPsec, back in 1995, which I think is fair to think of as mostly "professional software developers", was clearly warned about potential consequences of some of their design choices[2] (like using Encrypt-then-MAC), but they reacted quite harshly to his comments and did not take them as seriously as they should have, and actual attacks were demonstrated on those issues years later[3]. For me, reading the mailing list is enough evidence that it is very dangerous to draw the line between secure protocol design and other things. Similarly, I believe the lack of understanding of the reasons behind design choices in a protocol specification will surface as implementation bugs done by purely "secure software development" experts (e.g. "optimization" of random data generation at the beginning of the protocol to use in place of an invalid input by reordering the operations leading to a timing attack in TLS). There is enough historical evidence that makes…