Grasshopper Loading Error

Replies to This Discussion

Permalink Reply by Brian Gillespie on March 31, 2014 at 10:23am

Thanks for getting in touch with us. I've seen this kind of error before, and will need to work with David Rutten, the Grasshopper developer, to resolve it.

I believe what is happening is that somewhere in the Grasshopper code, an encryption algorithm is being used. But the implementation of that encryption algorithm has not been certified for use on US Government systems such as yours. The solution to this problem is likely to change the encryption implementation being used, or disable encryption for the function that is using it.

There are several posts on the internet about how to disable FIPS validation of cryptographic standards, but that isn't possible in this case, as the US government and military computing systems have this set intentionally.

David, it looks like GH_IconTable uses the MD5 algorithm to create a hash of the icon, and while you're not using it to store sensitive information, the FIPS validation doesn't allow you to use it at all.

This article may be useful for finding a suitable algorithm for use when FIPS is enabled:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/e0b4493f-6e20...

If this code is all runtime code, we can just switch algorithms. Otherwise, you may need to detect whether FIPS is enabled, and use different encryption algorithms. It looks like the check is:

Utils.FipsAlgorithmPolicy == 1 (cited at http://stackoverflow.com/questions/939040/when-will-c-sharp-aes-alg...)

Permalink Reply by Tristan Wolfe on March 31, 2014 at 10:43am

Thanks, Brian & David. I have no clue what you just said, but I'm excited to watch "the pros" troubleshoot this issue. (Nothing is ever simple with the US Gov.)

 

Navy. Accelerate Your Life.

Permalink Reply by David Rutten on March 31, 2014 at 12:06pm

There are algorithms which create hashes from data. These hashes always have the same size, irregardless of how many bytes the original data had. It is thus not akin to compression. For a hash to work well, very similar input data must result in wildly different hashes. For example, imagine we have an algorithm which computes hashes of text, and the hashes it computes are all numbers between 0 and 999. We then apply this algorithm to a piece of text:

"When Spring comes back with rustling shade" = 385

So far so good. Now imagine we change the text slightly, for example by removing a single "l":

"When Spring comes back with rusting shade" = 973

Minor change -> very different hash. There are of course way more unique texts than there are numbers between 0 and 999. This must therefore mean that a lot of text will result in the same hash. For example "When Spring brings back blue days and fair." may also result in a hash of 385. Because of the pigeonhole principle, there is nothing to be done about this.

Now for the tricky bit. Hashes are often used to validate executable code. Say your friend James at MI6 sends you a small program that will allow you to eavesdrop on Angela Merkel, and -over the phone- he tells you the hashcode for that application. You can then hash the application yourself, verify that it indeed results in the same hashcode and then you know you can trust the executable.

But now Jack from the FBI intercepts the email and adds a few sneaky lines of code to the original application allowing him to determine from your internet search history with up to 95% accuracy whether you like extra cheese on your pizza. The application has now been tampered with, it can no longer be trusted and you should be able to figure this out as it will no longer result in the same hash code.

But wait! Some hashing algorithms are more secure than others. MD5 is now officially considered to be 'hacked' and it is no longer recommended for doing naughty spying. Specifically, Jack will be able to inject his own code in such a way that it does not result in a different hash. Instead, the SHA family of hashers are to be used, as it is not yet known how to trick these hashers.

This is where the problem comes in, because apparently the US government has forcefully disabled the use of MD5 for all purposes. This is a shame because I use it to quickly compare bitmap icons for identicalness so I only have to store an icon in memory once. There is no security hole due to this, because I'm not hashing secure data. MD5 is somewhat faster than SHA, and since I have to hash several hundred icons on Grasshopper start, I opted for the faster one.

(Very) long story short; you're hosed. Grasshopper uses MD5; USgov does not like; Grasshopper does not run on USgov computers.

I'll do some testing to see if I can switch to SHA and then we can see whether or not that solves the problem. This however will take a while as I'm going on a business trip next week and have yet to prepare my presentations.

--

David Rutten

david@mcneel.com

Permalink Reply by Tristan Wolfe on March 31, 2014 at 12:34pm

David/Brian,

One thing that I didn't notice before (because I had no clue what Grasshopper is SUPPOSED to look like, this is the first time I've tried using it) is that none of the icons show up, making Grasshopper very unusable for me.

It looks like you might be on to something. When you said that Grasshopper does not run on US Gov computers I said "nonsense", because the scripts I'm trying to run were made by a US Gov computer. I went back to the source who made the files and had him launch Grasshopper. He suddenly has the same issue, meaning that at some point something was probably pushed onto our networks, disabling our ability to use Grasshopper.

However, he said he remembered seeing this problem before and posted something in the Rhino forums that I'm going to attempt to dig up. He said he changed a setting in Rhino and it worked after that, but those were also on older builds of Rhino/Grasshopper. I'll keep you updated if I find the solution he used.

Thanks,

Tristan

Permalink Reply by Mathias s n on February 5, 2018 at 2:57am

Hi David,

We're trying to compare geometry in a simple  way - can we make a md5 hash of lets say group of points, breps etc etc? Based on the raw data the item contains? And not the guid.

/M

Permalink Reply by David Rutten on March 31, 2014 at 12:07pm

Thanks Brian,

this indeed seems to be the way forward.

--

David Rutten

david@mcneel.com

Permalink Reply by Marvin on March 31, 2014 at 12:46pm

David,

Thank you for your attention to Tristan's problem. I am another user experiencing the same problems and would love a resolution.

 

Regards,

Marvin

Permalink Reply by David Rutten on April 1, 2014 at 2:44am

I've send you and Tristan a private message with a test-build to try.

If this quick fix doesn't work it'll be two weeks before I can investigate more deeply.

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on March 31, 2014 at 1:34pm

Am i right in thinking that this process is designed to speed up Display Icons mode? If so can there not be a check for US Gov PCs and disable Display Icons

Permalink Reply by David Rutten on March 31, 2014 at 2:29pm

It's not meant to speed up display, it's meant to avoid having the same icon loaded into memory more than once. Now all the components (be they on the toolbars or the canvas) that have the same icon all use the same memory.

I'm not entirely sure I can reliably check whether FIPS is enabled. There are some registry keys that will indicate with a high degree of probability what the setting is, but they are in different places for different framework versions and they cannot be fully relied upon. However it seems the MD5 simply refuses to be created when FIPS are on which I can detect, and then move on to some other hasher. 

--

David Rutten

david@mcneel.com

Permalink Reply by Marvin on April 7, 2014 at 6:29am

David,

Thank you for your quick response, it was quite impressive. Your fix worked and we are up and running once again.

Regards,

Marvin