Leaderboard

I would like to offer my SHA-1, SHA-2 HMAC and AES files to OpenG to add to the MD5 library (I suppose we need to rename that palette). You can find these functions currently in the LAVA Code Repository. The code is currently in 2010, but I can backsave to 2009. Ton

This OpenG Review is now closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread. VI Name: String to char array Total VIs: 1 Description: This VI creates a array of characters of a string. It splits a string every character. Note: Maybe there should be added another input with which you can tell that the string needs to be splitted every 2/3/4... chars instead of every char. This can easily be done by using the counter in the for loop together with modular arithmetic and a case structure. Blockdiagram: Code: String to Char Array.zip What are you thoughts on this VI? Would you like to see such a function in OpenG? Can you optimize the code? In which package should it be included? Should it be rejected?

Simple String Subset is almost 3X faster in this case. Subroutine priority makes it slightly faster as well. To Character Array_DK.vi

I have also been told that fools seldom differ.

I find the VI useful and I think it should be part of OpenG. I made the following modifications for speed: But when I benchmark it some times it is faster, but some times it is not. It seems that the original version is more consistent: Original code: Modified code: I am attaching the Benchmark VIs I used: TEST - To Character Array-modified.vi BenchMark-To Character Array-modified.vi BenchMark-To Character Array.vi Fab I guess I need to learn to post a lot faster !!! But hey, great minds think a like

One of the flags (mods) of the Mouse Down event is 'Double Click': Ton

Name: Encryption Submitter: Ton Plomp Submitted: 07 Sep 2011 Category: *Uncertified* LabVIEW Version: 2010 License Type: BSD (Most common) This package consist of a series of tools in native LabVIEW 2010 code. For encryption/decription the AES (Rijndael) routine is used with key sizes of 128, 192 and 256 bytes. The encryption supports the following block modes: EBC CBC CFB128 OFB For signing of string/packages it performs the SHA-1 and SHA-2 hashing, for MD5 hashing the OpenG functionality is used. The hash functions return a binary string and a hex-formatted string with the hash. The following hashes are supported: MD5 (via OpenG library) SHA1 SHA-2 224 bit SHA-2 256 bit SHA-2 384 bit SHA-2 512 bit For Hashed key authentication the HMAC functionality is provided based on the supported hash functions. The used functions are tested against NIST public test vectors. The use of these functions is not: secure the code does not try to protect it's memory nor the used keys. © Ton Plomp 2011 - No warranty implied. Click here to download this file

Jon, I don't see where this happens. Inverse cypher returns the data just as the input of the cypher, however the control is set to HEX-display (very usefull during debuggin), if you drop a control based on that you definitly get something different than you expect, but you shouldn't need to use an additional conversion. Yes/No, it would be nice if there is some standard of padding... I've looked throught several NIST documents and they only mention padding with 'nulls', not defining an official accepted form of padding. Note that padding depends on the type of block mode you use. Ton

OpenG Cryptography Library

If you look carefully at some of the LabVIEW posts regarding Nagle's Algorithm, you can find references to (or actual) VIs that you can use to toggle Nagling on a PER CONNECTION BASIS within your LabVIEW code. You certainly can make changes in Windows (via the registry) but this will affect all apps.

I (personally) think this VI is a good OpenG candidate. Therefore I have OpenG'd the code and included a Test VI. Please discuss. I was unable to optimise the code further - can anyone make it faster? To Character Array.vi TEST - To Character Array.vi Code is in LabVIEW 2009.

There must be a LabVIEW.ini key that let's you create these.

FWIW, when I have to do this I like to use the following convention: If the Label is red (BD and FP), its dependent so don't go changing it. I think I copied it off someone after seeing it on LAVA (thanks to Olivier I think )

Here it is ! You can download the last version of SAPHIR probes (I hope that the update will be available directly through VIPM next week). The package contain the new probes presented in this post, with a few enhancement. We've also added probe named Chronograph. As the one presented in this post by MikaelH, Chronograph probe allows you to measure time between it and any other SAPHIR probes. It could be very useful for a quick code execution time checking. Finally, we've tried to standardize every probes ui in order to have resizing capabilities and add "freeze" and "clear" graph button when it was necessary. Hope you'll enjoy this new package. If so, feel free to leave a comment here. Note about ui rendering on Windows Seven : Probes was originally designed on Windows XP. Using them on Windows 7, we've came across some ugly ui rendering following OS display settings. You can see the worst example below : History probe under XP : Same probe under 7 : We've tried to mange it as best as we've can, feel free to give us feedback on this point. Olivier. saphir_lib_vibox_probes-1.2.0.18.vip

Currently I use it to split a string into chars and then randomize the array. Shortly put to shuffle a string. Further it can probably be used to spit a binary string to afterwards cast it to a integer. Further: http://www.dotnetperls.com/tochararray