search

SparkDustJoe / TripleSecManaged

A C# port of the TripleSec encryption scheme created by Chris Coyne, Maxwell Krohn, and Filippo Valsorda
https://keybase.io/triplesec/
Other
21 stars 4 forks source link

Implement v4 when fully released by the Keybase.io team #1

Closed SparkDustJoe closed 5 years ago

heronhaye commented 5 years ago

Hi, Sorry about the delay in getting the docs out. https://keybase.io/triplesec is updated. Only differences are dropping the Twofish phase and switching from Keccak to the SHA3 standard. If you like, you can add support for encrypting and decrypting v4 ciphertexts to your library. Let me know if you have any questions about the spec.

SparkDustJoe commented 5 years ago

It's on my road map. Thanks for the heads-up!

SparkDustJoe commented 5 years ago

@heronhaye Is there a specific reason the TwoFish layer was removed and not replaced with anything else? If you're only doing two passes, wouldn't that make this Doublesec? ;)

heronhaye commented 5 years ago

Sorry for the late reply. We felt that because Twofish is so old, a lot of platforms and languages don't have reliable implementations of Twofish written by cryptographers. Note that side channel attacks in flawed implementations can still affect security in triplesec, even if it's only in one of the algorithms.

It is true that we only have two ciphers now. We wanted to replace it with another one but we couldn't find one that's relatively standard and widely-accepted. If you have a suggestion, we can consider it for version 5. Thanks!

SparkDustJoe commented 5 years ago

I would say to stick with whatever comes out of CAESAR, but doing so negates some of the need for multiple hash functions, and might facilitate a move to AES-GCM, and XSalsa20-Poly1305. In fact, if every layer is switched to an AEAD then the hash is just for preflight checks rather than serious verification.

But that's just my opinion...

SparkDustJoe commented 5 years ago

If after going to some AEADs and you still want to have multiple signatures, I would say XOR them together, and put them at the end as was previously suggested to facilitate easier verification (continuous block of data for the header and the ciphertext rather than breaking it into two separate but related blocks).

heronhaye commented 5 years ago

CAESAR

That sounds promising. Do you know when the finalist will be chosen? I can't find a date at https://competitions.cr.yp.to/caesar-submissions.html.

I'm always a big fan of AEAD but I don't know of any results relating to how the composition of AEAD schemes affect integrity. Of course, if we still end up adding the hashes to the end, it definitely can't hurt. XORing two hmacs together seems sketchy however (I think this is similar to what older versions of TLS did?), as opposed to just concatenating.

SparkDustJoe commented 5 years ago

These hashes are keyed, and produced from two separate algorithms (structurally speaking), and AEAD has its own integrity checking built-in, so the level of jack-assery that an adversary could pull is limited and containable like any other proper crypto system (IMHO). I was rooting for NORX but apparently it doesn't perform as well as the other candidates, at least not in their testing. I'm weary of constructions relying on AES-NI instructions just in case a break is discovered; it has wide-spread consequences given the level of adoption. We don't want to end up with another WEP/RC4/TripleDES situation... but I digress.

I just overhauled my SHA3Managed library to make V3 and V4 better overall (less duplication of buffers and arrays) when calculating signatures. So my road map for V4 is coming along nicely.

@heronhaye Do you guys have a full suite of proper test vectors built up for V4? If not, I can come up with a GIST for V4 like I did for V3 and make it part of the repository here so that you guys can run against it and see if we agree.

EDIT: This -> https://gist.github.com/SparkDustJoe/845c6502253f9ff8398a

heronhaye commented 5 years ago

@SparkDustJoe We have test vectors at https://github.com/keybase/triplesec/blob/master/spec/triplesec_v4.json (r is the random tape) but they're not as debug-friendly as yours. Let me know when you've made your gen 4 vectors and I can run it against our {python,go,js} implementations.

SparkDustJoe commented 5 years ago

See here for my test vectors and results (all in HexBytes) https://gist.github.com/SparkDustJoe/f7316559fc8520dd82dc43b1358ac89f

Let me know if you get different values. The RNG raw output is included in these vectors for the IVs and Salts. I'll incorporate yours with mine when I update/sync the repo that includes the final V4 code. I'll also put the intermediary values for XSalsa20 in there for the final gist that I publish so that it's more in line with V3.

Looking forward to V5 ;)

SparkDustJoe commented 5 years ago

I seem to be in agreement with your 6 tests. :) c0ae0cd9d7106718c9f293cecabb8bcf827af6ec

heronhaye commented 5 years ago

Sorry for the delay. Your test vectors check out on my end. Feel free to ping us on the keybase/triplesec repo when CAESAR concludes!

SparkDustJoe commented 5 years ago

Great, thanks for following up. 👍

SparkDustJoe commented 5 years ago

The final CAESAR portfolio has been announced: https://competitions.cr.yp.to/caesar-submissions.html