Threefish

[Collin Stocks]

I'm not really sure if this is the best place to post a suggestion, but the wiki said it was, so here goes:

I think it would make sense to offer an implementation of Threefish (developed in part by Bruce Schneier and Niels Ferguson), since it is a reasonably fast block cipher, is tweakable, and is the only serious block cipher (that I know of, at least) to offer a very wide variant (1024 bits wide). Additionally, it avoids cache-timing attacks by not using S-boxes or table lookups (something which I am absolutely sure you address in your implementation of AES, but all the same it is nice to know that one is using a block cipher developed explicitly to avoid such problems).

Better still, the C reference implementation of Threefish provided by the group that developed it is uncopyrighted, so it should be able to be included in this project with minimal effort.

Anyway, this is just a suggestion I thought I would bring up, since it would be nice to have more ciphers to choose from, and the reasons given above for including this particular cipher.

-- Collin

[Nick Pateman]

If its available and you get it done please share. Sorry for not offering help.

Sent from my iPad

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[collin...@gmail.com]

I would be glad to write an interface to the existing Threefish code to be incorporated into Crypto++, but I am not sure what the correct course of action would be.

Is there a version controlled version of the source I can fork, edit, and submit a pull request (or similar process)? Or should I just download the last release version (5.6.2), edit that, and then send a patch?

Based on the release dates, it does not appear that there is a huge amount of active development (as seems logical for a crypto library that must always remain stable), and that the most recent release followed the announcement of SHA-3 (with a suitable delay to ensure correct implementation). With that in mind, is there a development version I should create a patch for, or would the most recent release version be best?

Finally, while I am at it, is there any interest in also wrapping Skein (one of the finalists in the SHA-3 competition)? Personally, I have no need for it, but I think there is value in providing different options for people to use. However, if there is no interest, I probably won't bother trying to add the extra functionality (on top of the wrapper for Threefish that I plan to write already).

-- Collin

[Jeffrey Walton]

On Mar 21, 12:16 am, "collinsto...@gmail.com" <collinsto...@gmail.com>
wrote:

> I would be glad to write an interface to the existing Threefish code to be
> incorporated into Crypto++, but I am not sure what the correct course of
> action would be.
>
> Is there a version controlled version of the source I can fork, edit, and
> submit a pull request (or similar process)? Or should I just download the
> last release version (5.6.2), edit that, and then send a patch?

Wei is surely the definitive answer here. With that said, checkout
from SVN (http://www.cryptopp.com/wiki/SVN) and develop the
patch.There's lots of other existing cipher and hash code available,
so you have lots of working examples.

Email the patch to Wei or the list for possible comments and
inclusion. Be sure to include self tests. If you don't hear back, he
is probably busy. In that case, place the patch on the wiki.

Write the wiki page as if its actually part of the library. Be sure to
state its a patch that's not part of the library. Obviously, include
the patch for download. Similar was done for FHMQV (http://
www.cryptopp.com/wiki/Fully_Hashed_Menezes-Qu-Vanstone). Its available
as a patch for those who are interested.

As I said, Wei is the gatekeeper. The other stuff is just my opinion.

Jeff

[James Kelvin]

Hi,

Is there any progress in the Threefish/Crypto++ implementation?

Thanks
J.K.

On Thursday, March 21, 2013 5:16:00 AM UTC+1, Collin Stocks wrote:

I would be glad to write an interface to the existing Threefish code to be incorporated into Crypto++, but I am not sure what the correct course of action would be.

Is there a version controlled version of the source I can fork, edit, and submit a pull request (or similar process)? Or should I just download the last release version (5.6.2), edit that, and then send a patch?

Based on the release dates, it does not appear that there is a huge amount of active development (as seems logical for a crypto library that must always remain stable), and that the most recent release followed the announcement of SHA-3 (with a suitable delay to ensure correct implementation). With that in mind, is there a development version I should create a patch for, or would the most recent release version be best?

Finally, while I am at it, is there any interest in also wrapping Skein (one of the finalists in the SHA-3 competition)? Personally, I have no need for it, but I think there is value in providing different options for people to use. However, if there is no interest, I probably won't bother trying to add the extra functionality (on top of the wrapper for Threefish that I plan to write already).

-- Collin

On Wed, Mar 20, 2013 at 6:43 PM, Nick Pateman <nick.p...@certivox.com> wrote:

If its available and you get it done please share. Sorry for not offering help.

Sent from my iPad

On 20 Mar 2013, at 22:06, "Collin Stocks" <collin...@gmail.com> wrote:

I'm not really sure if this is the best place to post a suggestion, but the wiki said it was, so here goes:

I think it would make sense to offer an implementation of Threefish (developed in part by Bruce Schneier and Niels Ferguson), since it is a reasonably fast block cipher, is tweakable, and is the only serious block cipher (that I know of, at least) to offer a very wide variant (1024 bits wide). Additionally, it avoids cache-timing attacks by not using S-boxes or table lookups (something which I am absolutely sure you address in your implementation of AES, but all the same it is nice to know that one is using a block cipher developed explicitly to avoid such problems).

Better still, the C reference implementation of Threefish provided by the group that developed it is uncopyrighted, so it should be able to be included in this project with minimal effort.

Anyway, this is just a suggestion I thought I would bring up, since it would be nice to have more ciphers to choose from, and the reasons given above for including this particular cipher.

-- Collin

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.

To unsubscribe, send an email to cryptopp-use...@googlegroups.com.

More information about Crypto++ and this group is available at http://www.cryptopp.com.
---

[Jean-Pierre Münch]

As everyone here seems to be too lazy to do this, I'll share the results of my work.
This was intended to be used for a private project, but I guess it would be ok, if you guys use it too.

Basically it's Skein3Fish's fully unrolled code packed into a helper file, and with an interface to Crypto++.

Code's attached.

BR

JPM

[Jeffrey Walton]

> As everyone here seems to be too lazy to do this,

Well, you're making friends :)

On Monday, November 24, 2014 10:07:48 AM UTC-5, Jean-Pierre Münch wrote:

As everyone here seems to be too lazy to do this, I'll share the results of my work.
This was intended to be used for a private project, but I guess it would be ok, if you guys use it too.

Basically it's Skein3Fish's fully unrolled code packed into a helper file, and with an interface to Crypto++.

Code's attached.

...

[Kelvin J]

Thank you very much for your Threefish implementation.

However it doesn't work as I expected .

I have encountered a problem with key size. Regarding specification: Key
sizes are 256, 512 or 1024 bits (key size is equal to block size).

For example - your implementation of 1024bit version refuses 128B key and
demands 144B (1152bit):
/struct Threefish1024_Info : public *FixedKeyLength<144>*, public
FixedBlockSize<128>, public FixedRounds<80>/

So I'm little confused - don't know maybe I have missed something.



--
View this message in context: http://crypto-users.996303.n3.nabble.com/Threefish-tp4700p5250.html
Sent from the Crypto++ Users mailing list archive at Nabble.com.

[Jean-Pierre Münch]

 First I want to clarify that the only work I did was to take Skein3Fish's code and  adapt if for Crypto++;

you might've read that I was using this code for private purposes and shared it because there was a need, so I didn't document where those extra 16 Bytes come from.
You might or might not know that Threefish normally accepts 4 Parameters: Key- (and Block-)size, Key, IV (if any) and Tweak.
As there's no standard in Crypto++ concerning tweakable blockciphers (to which Threefish belongs) I took the standard I found and did my best to integrate Threefish into it.

The purpose of those 16 extrabytes for every single blocksize is, that they're the tweak. So you're essentially specifying (is that spelled right?) Key||Tweak (or other way around, don't remember).
So the tweak is basically taken as part of the key because I think that's the best way - besides implementing a whole new concept - of integrating Threefish.

BR

JPM

[Kelvin J]

Sorry, I understand now, tweak is bundled along the key.


Kelvin J wrote

> Thank you very much for your Threefish implementation.
>
> However it doesn't work as I expected

> .
>
> I have encountered a problem with key size. Regarding specification: Key
> sizes are 256, 512 or 1024 bits (key size is equal to block size).
>
> For example - your implementation of 1024bit version refuses 128B key and
> demands 144B (1152bit):
/
> struct Threefish1024_Info : public
*
> FixedKeyLength<144>
*
> , public FixedBlockSize<128>, public FixedRounds<80>
/
>
> So I'm little confused - don't know maybe I have missed something.





--

View this message in context: http://crypto-users.996303.n3.nabble.com/Threefish-tp4700p5252.html

[Jeffrey Walton]

On Tuesday, December 9, 2014 10:12:09 AM UTC-5, Jean-Pierre Münch wrote:

Am Dienstag, 9. Dezember 2014 02:29:30 UTC+1 schrieb James Kelvin:

Thank you very much for your Threefish implementation.

However it doesn't work as I expected .

I have encountered a problem with key size. Regarding specification: Key
sizes are 256, 512 or 1024 bits (key size is equal to block size).

For example - your implementation of 1024bit version refuses 128B key and
demands 144B (1152bit):
/struct Threefish1024_Info : public *FixedKeyLength<144>*, public
FixedBlockSize<128>, public FixedRounds<80>/

...

You might or might not know that Threefish normally accepts 4 Parameters: Key- (and Block-)size, Key, IV (if any) and Tweak.
As there's no standard in Crypto++ concerning tweakable blockciphers (to which Threefish belongs) I took the standard I found and did my best to integrate Threefish into it.

You might want to look at the way Crypto++ provides an interface into authenticated encryption modes like EAX, CCM and GCM. Authenticated encryption modes allow variable length authentication tags, and that does not seem too different than the tweak on tweakable modes like OCB and Threefish.

Jeff