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!
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
>Is this really 'newsworthy'?
inasmuchas anything newsworthy for nerds can be said to be non-newsworthy for nerds, and the line between nerd and non-nerd moves with the subject, then yes, this could be newsworthy for bash or skein nerds
on the other hand, it's the first i've heard that they were cooking up a SHA-3. so maybe there are multiple layers of nerdiness involved.
tomorrow i expect to see your posting of how you've implemented it in brainfuck.
Now do the validation suite for it. That's really the hard part.
Bah -- fixing my link. http://www.schneier.com/book-applied.html
it's the first i've heard that they were cooking up a SHA-3. so maybe there are multiple layers of nerdiness involved.
It's hardly the first time it's been mentioned on Slashdot.
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")?
What is bf?
Sig ?
Agreed. Why wasn't this done as a Perl golf contest?
Welcome to the Panopticon. Used to be a prison, now it's your home.
/. 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!
Newsflash: a known algorithm implemented in a Turing-complete language poorly suited for that algorithm
fixed that for you.
I implemented it last night using my abacus and slide rule
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
I second this.
Michael
http://s1.sfgame.us/index.php?rec=58163
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.
Yes, I actually saved that post all these years. It's funny.
C|N>K
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?
I always like to challenge people to try it in Brainfuck or with a single instruction computer. Turing completeness is more of a theoretical thing as it ignores difficulty, and polynomial time Turing machine stuff only partly captures that.
-- The Grand Teddy Bear has Spoken: "Windows 8 Source Code Available NOW! more disgusting than your pr..."
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
There's nothing in it that fundamentally requires bash, you just need a shell which supports arrays. It might not perform as well, however, without some of the bashisms. I'd say porting this will be of minimal effort.
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.
I've done it on my (purely theoretical) single instruction computer.
Now, it wasn't exactly difficult because the single instruction of that computer has been well chosen.
Here's the implementation:
The Tao of math: The numbers you can count are not the real numbers.
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.
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.