Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
RadioGatún[64] disabled
11-24-2013, 12:46 PM (This post was last modified: 11-24-2013 01:56 PM by samiam.)
Post: #1
RadioGatún[64] disabled
Original posting

I have disabled the compile-time option to have RadioGatún[64].

This code is not needed. Even though RG64 is faster, even on 32-bit systems, it uses more code on 32-bit systems (breaking Deadwood's ability to fit in 65,536 bytes on Windows).

In addition, this code does not have a test for it. RG32 is good enough; if I'm going to update Deadwood's crypto, do it right: add SipHash, add Keccak, add maybe another stream cipher. But, quite frankly, that probably will not happen unless some academic paper comes out questioning either Panama's or RadioGatún[32]'s security as a stream cipher.

The fact of the matter is this: While it is a lot of fun to play around with cryptographic primitives, the choice of cryptographic primitive is usually not the cause of security or performance problems. Yes, Keccak fixes some theoretical issues with RadioGatún's security when used as a cryptographic hash -- but those issues are nowhere near a practical weakness in RadioGatún right now, and probably will never result in a real-world attack. More to the point, Deadwood doesn't use RadioGatún as a cryptographic hash, but as a stream cipher, and there is no known attack against either Panama (RadioGatún's predecessor) or RadioGatún used in this manner.

While RadioGatún[64] is faster than RadioGatún[32], this is not Deadwood's bottleneck. Deadwood's main performance bottleneck is waiting for an upstream DNS server to reply to a query, or moving on to the next DNS server if there is a query timeout.

This update can be downloaded here:

http://maradns.org/deadwood/snap/
Visit this user's website Find all posts by this user
Quote this message in a reply
11-24-2013, 02:30 PM (This post was last modified: 11-24-2013 05:56 PM by samiam.)
Post: #2
RE: RadioGatún[64] disabled
I think the reason why RadioGatún[64] is so fast on 32-bit x86 systems is because x86 can handle rotates for words bigger than the system registers quickly:

http://en.wikibooks.org/wiki/X86_Assembl...structions

(Called Double precision shifts in some literature)

Compare this to ARM, which doesn't appear to have an efficient multi-word shift operation:

http://www.peter-cockerell.net/aalp/html/ch-3.html

It would be interesting to see compare how fast RadioGatún[64] is compared to RadioGatún[32] on an ARM system...it may be slower.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)