Slashdot Mirror
Skein Hash... In Bash
First time accepted submitter Matt16060936 writes "...Last night (err.. 3am this morning) I finished an implementation of the Skein 512-512 hash algorithm (version 1.3). I'm a fan of Skein and hope it wins the SHA-3 competition next year. One of the nice things about Skein is how quickly it's been adopted by many platforms and implemented in many languages. To that end, I present Skein 512-512 implemented in Bash."
The cause of, and solution to, all of life's problems. Here's to Bash! If it weren't for you, I would be a terrible sysadmin. Thanks to you, I am a terrible sysadmin!
wtf is wrong with you
The Wikipedia article states: "The function is optimized for 64-bit processors". On a 32-bit computer, the Bash program will die with an error message "This program is written for 64-bit architectures." So if Skein is adopted as SHA-3, it might run unacceptably slowly on as legacy PCs with pre-x86-64 CPUs and on handheld devices with an ARM CPU.
Damn. Slashcode won't let me post the Skein encrypted version of first post (Filter error: That's an awful long string of letters there.)
which is totally what she said
Amazing how code is always produced in the middle of the night...
Why didn't you post this on Github?
At least it has syntax highlighting, I'm no expert at Bash, but I don't think anyone would appreciate reading it with no syntax highlighting.
Come back with the intercal implementation.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Sadly the hash of the bash script is only marginally less readable to me than the source.
I've had times when I'd have found it useful to have something like base64 or md5 in shell script form to require less dependencies on ancient installations, assuming it could be made work with anything approaching acceptable performance.
Unfortunately this isn't it. A 194 bytes file took 3 seconds. The skein script (10K) takes 2 minutes and half, and it's ridiculously memory intensive too. The process grew to 150 MB in size.
Matt Tomasello for:
echo 'Usage: cat FILE | skein [ARGS]'
...not to be confused with Skin Rash.
/* No Comment */
978-0517545164
Don't get me wrong... as a coder I'm all up for stuff being done on with an inappropriate language choice just for shits and giggles or to see if it can be done... but why the hell is some guy's bash script making the front page? Is this really 'newsworthy'? (Yes yes, I must be new here.)
Bash can be a great language and although it can sometimes be a stretch, its generally possible to massage anything out of it that you would do in any other sane procedural language (as long as you don't care about runtime). As someone else said, something done in a turing tarpit such as intercal would be much more impressive!
Heh yeah I think it was IBM that posted all the misuses of the shell and misusing cat particularly with grep was one of them.
It could easily be:
skein [args] FILE
Newsflash: a known algorithm implemented in a Turing-complete language. Uhm...
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Bah typed that from a phone so there was no HTML typed slashdot removed the less than symbol between args and FILE
Now do the validation suite for it. That's really the hard part.
Bah -- fixing my link. http://www.schneier.com/book-applied.html
Kudos, submitter!
This is the kind of stuff Slashdot needs more of.
I'm sick of Slashvertisements and Idle garbage I can find on reddit.
Looks very entertaining, will make a great fit for an old unix admin/friend and cat lover.
If the Skein bash function was written to take in text input and spit out a hash, using cat would allow using a filename as the source of the text you want SKEIN'd. If you tried doing "Skein [args] FILE", you would just get the hash of the filename.
How do you propose the SKEIN function determine whether the second argument is a filename, or the text to be hashed? Should he add that funciton as a further switch, and also implement the function of reading the contents of a file (which would presumably use "cat")?
/. ate his "less than" sign. What he means to say is:
Where bash handles opening, reading, and piping the file into STDIN. No need to start another process.
Give me Classic Slashdot or give me death!
Would it be to port this BASH script to other shell's scripting languages; that is something I'd like to see?
I would recommend the standard Unix conventions for stuff like this:
$ skein [args] [file] [--text 'some text']
"Be grateful for what you have. You may never know when you may lose it."
n/t
Am I being trolled?
If the Skein bash function was written to take in text input and spit out a hash, using cat would allow using a filename as the source of the text you want SKEIN'd. If you tried doing "Skein [args] FILE", you would just get the hash of the filename.
skein < FILE
surely?
Look at page 25 of the Skien Whitepaper. Using C implementations, Skien-512 outperforms SHA-512 and Skien-256 is only about 75% slower than SHA-256 on a 32 bit CPU. That isn't unacceptably slow.
Although, as Hatta pointed out, slashcode ate his less than symbol, you're still incorrect. "skein [args] FILE" would only make argv[argc-1]="FILE" not the zeroth file descriptor (stdin) equal to "FILE", which is necessary if "echo FILE | skein [args]" and "skein [args] FILE" are to agree. If such a program was made to hash the last argument you'd have to go through a heck of a lot of work escaping your file contents and trying to avoid the maximum argument length.
Skein Hash in Bash gives me a rash.
That's why I go skiing at Attitash...
Matt Tomasello for:
echo 'Usage: cat FILE | skein [ARGS]'
I find this kind of pedantry a bit dull. When I'm hacking around on things at the command line I almost always use that form. If you're building up a pipeline of various parts to get something done, and you need to insert at the beginning, or reorder components, it's much easier if the input to the pipeline is a clean, separate term.
Trivial example:
cat FILE | foo is easily edited to head FILE | foo in a way that foo < FILE is not.
Be careful. People in masks cannot be trusted.
How do you propose the SKEIN function determine whether the second argument is a filename, or the text to be hashed? Should he add that funciton as a further switch, and also implement the function of reading the contents of a file (which would presumably use "cat")?
Simply put, you follow the conventions established by md5sum and other command line hashing tools that have existed for many years/decades prior.
Wolde you bothe eate your cake, and have your cake?
Hacking around on the command line is one thing. Writing examples is another. When you save your code for long-term re-use or reference purposes it should be well written.
I want my Cowboyneal
But what's the problem with using cat here? It's not necessary, but it doesn't harm either, does it?
Also, well written code means maintainable code. Maintainable code means code that is easy to change. Which speaks for cat.
BTW, I've even found uses for the apparently useless use of cat in cat | command or command | cat (note: no filename on the cat!). That's when using programs which test whether standard input or standard output is a terminal, and I want the non-terminal behaviour even though I'm typing in a terminal.
The Tao of math: The numbers you can count are not the real numbers.
Seems the 64bit check fails under Power (bash 2.05b/ppc64).
Seems I have a Zero bit system! :-)
Would that involve adding more bash code to his already long script that he probably doesnt ever want to have to re-work on?
Also, as others have pointed out, you could use unix file pipes to handle reading the file; adding more arguments to it really would be retarded.
No, I didnt think of that as I deal with Linux CLI for about 10% of my job and I usually dont deal with reading input from files. It has been a long, long time since I have used that file pipe. I used to deal with it in Windows, and I got tired of using it when it didnt work properly with various commands (like set), so Ive always used alternatives, and that habit sticks with me in Linux as well.
Really, I dont get the big complaint about using cat to handle it, though, several people here seem to be advocating reinventing the wheel, and in bash script to boot.
It didnt eat my less than symbol, I just didnt think of using a file input pipe.
I use that style all the time, because:
cat file|grep something
allows you to change "something" very quickly - up arrow, alt-backspace and it's gone. By comparison:
grep something file
requires you to left-arrow to "something" before you can change it.
rubbish! modern compilers will optimi... oh.
That's redirection, not a pipe. A pipe was used in the original cat command.
and slashdot ate my tag.
Using cat effectively doubles the required IO operations.
A solution to your "left arrow to something":
arrow up
ctrl-arrow left
ctrl-w
But what's the problem with using cat here? It's not necessary, but it doesn't harm either, does it?
In fact it does do harm. Not even counting tangentials like "it encourages people to do this reflexively so they will get bitten when the difference really matters", it execs one more program and uses a good chunk more memory.
Maintainable code means code that is easy to change. Which speaks for cat.
I dispute that "cat foo | grep bar" is easier to change than "grep bar BTW, I've even found uses for the apparently useless use of cat in cat | command or command | cat (note: no filename on the cat!). That's when using programs which test whether standard input or standard output is a terminal, and I want the non-terminal behaviour even though I'm typing in a terminal.
In such a case it's both "not useless" and "being used interactively," where it probably matters less.
I want my Cowboyneal
On one of my systems:
me@here$ uname -m
i686
me@here$ getconf LONG_BIT
32
me@here$ echo $(( 1 << 32 ))
4294967296
me@here$ echo $(( 1 << 64 ))
1
Your test would consider my ARCH as 64 when it is clearly not. But then why does left-shifting 64 times not overflow?
<file grep something
There you go.