Semeir: 2.4.7 Released (SourceForge)
Semeir is a Encryption algorythmn, Capable of Stream and block encryption. It is written in pure C. It is platform independant, and is promising for Embedded systems. Intended as an alternate, yet secure data encryption cipher. It has been a long few years since I originally submitted Semeir. Starting its humble 1.0.0 that I was never released, to the 2.1.3 that some have tried out. I apologize for taking so long to release the next version, which was not ready until now; requiring a near complete re-write of some functions, and addition of new functions. As well as pre-built functions that are ready to use, when linked with Zlib."
Posted Mar 27, 2008 2:16 UTC (Thu)
by zooko (guest, #2589)
[Link] (14 responses)
Posted Mar 27, 2008 14:43 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (3 responses)
Now this is a first: Semeir's default initialized hash is an array of 9 char* strings that contain the lyrics to the Sheryl Crow song Wildflower. No, seriously! I agree, one should assume that this is snake oil. Perhaps its cipher and hash functions are robust, but we shouldn't believe so without thorough analysis and review. And besides, I'd much rather prefer the lyrics to the Kingsmen's cover of Louie Louie as my initial hash - they're already unintelligible as plaintext! ;-) I was taught in a computer security class: Never "roll your own" encryption. Use an existing crypt library (e.g. SHA, AES, etc.) that is still "...believed to be unbreakable."
Posted Mar 30, 2008 16:58 UTC (Sun)
by rtcvb32 (guest, #51336)
[Link] (2 responses)
Posted Apr 1, 2008 3:01 UTC (Tue)
by pr1268 (guest, #24648)
[Link] (1 responses)
Don't take my comments too seriously. If you are confident that your hash function (and any other cryptographic algorithms in your code) are indeed secure, then that's fine. I still stand by earlier quote about "never rolling your own encryption" - at least that's what I've been taught several times by some very well-educated computer scientist academicians. The existing hash and crypt functions widely used these days only got where they are due to years of rigorous analysis and stress-testing after RFC publication--I think that's why Bruce Schneier thinks that someone's claim that a hash function is secure without having first earned the respect and confidence of the security community is making an audacious claim (thus the "snake oil"). I'll take another look at Semeir and its code, because I'm curious what it can offer me. As for the Sheryl Crow lyrics, well, I was just surprised to see those, that's all. I do like her music (although I'm not familiar with her song Wildflower), and I sympathize with your sadness when writing the code. In retrospect, that was an innovative technique to fill up the hash buffers.
Posted Apr 1, 2008 4:48 UTC (Tue)
by rtcvb32 (guest, #51336)
[Link]
Posted Mar 30, 2008 17:13 UTC (Sun)
by rtcvb32 (guest, #51336)
[Link] (9 responses)
Posted Mar 31, 2008 6:42 UTC (Mon)
by jimparis (guest, #38647)
[Link] (8 responses)
Posted Mar 31, 2008 15:22 UTC (Mon)
by zooko (guest, #2589)
[Link] (3 responses)
Posted Apr 1, 2008 2:38 UTC (Tue)
by rtcvb32 (guest, #51336)
[Link] (2 responses)
Posted Apr 2, 2008 2:30 UTC (Wed)
by njs (subscriber, #40338)
[Link] (1 responses)
Posted Apr 3, 2008 5:39 UTC (Thu)
by rtcvb32 (guest, #51336)
[Link]
Posted Apr 1, 2008 2:19 UTC (Tue)
by rtcvb32 (guest, #51336)
[Link] (3 responses)
Posted Apr 1, 2008 4:20 UTC (Tue)
by jimparis (guest, #38647)
[Link] (2 responses)
Posted Apr 1, 2008 4:30 UTC (Tue)
by rtcvb32 (guest, #51336)
[Link] (1 responses)
Posted Apr 1, 2008 5:07 UTC (Tue)
by rtcvb32 (guest, #51336)
[Link]
Posted Apr 1, 2008 9:38 UTC (Tue)
by rtcvb32 (guest, #51336)
[Link]
Semeir: 2.4.7 Released (SourceForge)
Oh dear -- this has the hallmarks of bad encryption. Please do not rely on this for
high-value confidentiality. Read Bruce Schneier's notes on "Snake Oil Encryption":
http://www.schneier.com/crypto-gram-9902.html#snakeoil
Semeir hits several of the key points: a mistaken claim of being a "One Time Pad", and being
never (as far as I can tell) published or reviewed by serious cryptographers.
Snake oil *AND* a default hash initialized to Sheryl Crow song lyrics
Snake oil *AND* a default hash initialized to Sheryl Crow song lyrics
Perhaps i shall explain myself now, since obviously you didn't look at the code very well. I
do apologize that my documentation is less than perfect, and in some cases rather lacking.
That is my next project.
First off, the cipher is NOT snake oil. I have worked on this over several years in my 'off'
time. I have spoken at length with Bruce Schneier about a year to two years ago reguarding
employing encryption functions for improvements as well as for strength.
The Hash. Yes it does have a default hash, and yes it did have 'WildFlower' (I was depressed
in korea at the time) intended for testing purposes. If you dislike the song, i will happily
change them, but i didn't have anything else on hand that would have been halfway decent for
building it's internal crypto functions. Also note, although there are 9 levels for the hash,
it's accumulative, you can specify 1 (very fast) or as many as you want, the default was 9.
(Very slow). Also note that the blocksize is variable, meaning if you use the same hash, and
give 3 different block outputs, you most likely can not fake all three.
If i have mis-understood how hashing should work, i will change and fix it on another day,
that is low priority right now.
Snake oil. You are claiming the software i wrote is bad encryption. I have built tools built
into the distro (since it's still beta), that help with breaking each part of the program
apart for testing and improvement. Two such programs, are located at /apps/misc_apps/ and are
eval, eval_match. These two together will give you a bird's eye view of the different stages,
and how they use cipher-feedback in order to effect the whole block.
./eval [start blocksize] [ending blocksize] 2>&1 | ./eval_match | less
It is true, only i have worked on and tested the cipher, and i can't guarantee 100% that it
is a secure cipher. Then again, it is impossible with blocksizes between 1 byte and 15k.
One Time Pad (OTP). Perhaps the words are rather misleading, so i will describe the original
purpose of the functions. The one time pad was built for OTP encryption, but that wasn't it.
It was also for multiple random numbers, which when programmed right could have several or
seven hundred threads all with their own sets of random numbers, that won't get messed up, and
can individually get their own PRNG running at any time.
The OTP can work the way it suggests, by having a unique key, and a random seed (32-xxx bit),
and simply Xor the result against the data you want to encrypt, since it supplies a nearly
limitless supply. An example of the cipher using this, is in a working function inside
/src/prebuilt.c, which does the following stages.
1) Compress the data.
2) Generate random seed for OTP
3) Encrypt Text data with OTP
4) Encrypt whole block with Semeir
However it requires you to have a OTP and a key pair, which you can generate separately or
from a single source.
If you have questions on specific functions, i will talk about it in detail, explaining what
i did and why. Please, if anyone has any suggestions or comments for me, please send them to
me.
Era
Snake oil...
Snake oil...
>Don't take my comments too seriously. If you are confident that your hash
>function (and any other cryptographic algorithms in your code) are indeed
>secure, then that's fine. I still stand by earlier quote about "never
>rolling your own encryption" - at least that's what I've been taught several
>times by some very well-educated computer scientist academicians.
The Hash function, i do not claim is perfectly 'secure' to speak, at least one using only one
blocksize. Using multiple blocksizes it should be well enough for file verification, but true
authentic checking, i am not sure yet. The hash is far less tested then any of the other
functions, however it still relies on the encryption for it's unique return bits..
"never rolling your own encryption"
I agree, one should not make a encryption from scratch, at least not without much thought and
work. My original version has come a very very very very long ways, to where it is now,
believe me. (8 years actually)
Although lacking some documentation, 90% of important documentation is in includes/semeir.h
for each function and basic overall use. There's also /docs/HOWTO-semeir
>I think that's why Bruce Schneier thinks that someone's claim that a hash
>function is secure without having first earned the respect and confidence
>of the security community is making an audacious claim (thus the "snake
>oil").
Agreed, which is another reason this was released, so people interested can set multiple
tests against it. Weaknesses found will be fixed, should there be any. If there are no
weaknesses, it hopefully in the next 4 years can be accepted as a secure cipher/hash. In the
meantime, it's a experimental alternative.
I do consider the PRNG at cryptographic levels, although it might need some tweaking.
>I'll take another look at Semeir and its code, because I'm curious what it
>can offer me. As for the Sheryl Crow lyrics, well, I was just surprised to
>see those, that's all. I do like her music (although I'm not familiar with
>her song Wildflower), and I sympathize with your sadness when writing the
>code. In retrospect, that was an innovative technique to fill up the hash
>buffers.
I'm glad you can take a second look at it. Most of the insanely long functions are in
cipher.c and rand.c, aside from those, it's a lot more straight forward.
And thank you, although earlier today i had stripped it out of the 2.4.8 i'm working on;
should i leave them in perhaps? Or just change to a different flavor text? I'll leave for the
community to decide.
The largest reason i had a default hash was so if you had a file download. (oh, say from a
FTP site), and wanted verification it wasn't tampered with, you'd use the default hash, and
compare it against two sizes, like 160bit and 192bit. Which is what the experimental sem_md5
/apps/misc_tests/md5.c is for. Defaulted first hash, since more than that gets very slow.
Era
Semeir: 2.4.7 Released (SourceForge)
Please if you think i have done something wrong, E-mail me i'd appreciate that more.
I've commented lower, however i'll repeat a little.
According to my understanding, the One Time Pad (OTP) uses a constant 'RANDOM' string of
incoming data to offset the data you want to protect. The easiest way to do that is to build a
PRNG that has a large blocksize, and a very very large return before it repeats.
The only way to get that specific OTP, is to build the exact key (of unknown size), with the
exact seed (of unknown size), along with the EXACT offset. (unknown size).
I refer to unknown size since it is heavily dependent on the blocksize. If you have a
blocksize of 1k, a halfway strong password generated from some other source, and a secret
seed. It's highly doubtful anyone would find it.
http://en.wikipedia.org/wiki/One_time_pad
'A modular addition is used to combine the plaintext with the pad. (For binary data, the
operation XOR amounts to the same thing.)'
Era
Semeir: 2.4.7 Released (SourceForge)
> the One Time Pad (OTP) uses a constant 'RANDOM' string of
> incoming data to offset the data you want to protect. The easiest way to do > that is to
build a PRNG that has a large blocksize, and a very very large
> return before it repeats.
Yes, a proper OTP requires a unique stream of random data. So, for us to consider the
encryption secure at all, you need to demonstrate that Semeir's random number generator is
good. The burnen of proof is on you, not us.
Have you run tests on Semeir's RNG where you can provide quantifiable results? What are the
Diehard results, for example?
I tried to run some tests myself, but found that Semeir was painfully slow at generating
random numbers -- "semeir-2.4.7/apps/simple -r /dev/stdin /dev/stdout
this-is-my-super-secret-password | dd bs=4000 count=1000 of=random-data" took 30 minutes to
execute, and that generates only 1/10 of the amount of data that the Dieharder recommends.
/dev/urandom generates the same amount of data in under 2 seconds.
What are the benefits of Semeir that would make it a real contender to proven algorithms like
AES? Wikipedia says that "AES is fast in both software and hardware, is relatively easy to
implement, and requires little memory." Can you quantify in what ways Semeir outshines AES?
Semeir: 2.4.7 Released (SourceForge)
Technically, the phrase "One Time Pad" is reserved for a cryptosystem in which the pad is
completely random, not generated. The One Time Pad was formalized and its security proven by
Claude Shannon in 1949
http://en.wikipedia.org/wiki/Claude_Shannon
It is common for amateur crypto -- what Bruce Schneier calls "snake oil" when it is sold -- to
use the phrase "One Time Pad" to refer to a cryptosystem in which a pseudorandom stream which
is generated by computer (instead of a truly random stream, which by definition cannot be
produced by a deterministic computer program from a shorter seed) is added to the plaintext to
hide it. The fact that Semeir's documentation makes this mistake is the easiest way to tell
that Semeir has not been developed and analyzed by professional cryptographers.
I don't mean to hurt the feelings of the author of Semeir, and I don't mean to imply that he
is dishonest, but it is important to tell people not to rely on a cipher of this kind for some
use where the cipher's failure could cause harm.
Semeir: 2.4.7 Released (SourceForge)
>It is common for amateur crypto -- what Bruce Schneier calls "snake oil" when it is sold --
to
>use the phrase "One Time Pad" to refer to a cryptosystem in which a pseudorandom stream which
>is generated by computer (instead of a truly random stream, which by definition cannot be
>produced by a deterministic computer program from a shorter seed) is added to the plaintext
to
>hide it.
Note: When i say OTP, i am referring to my functions, labeled OTP.
Understood. But you also missed a very important aspect. The seed can be VERY VERY large. If
i've failed in that respect, i apologize, and yes the data is not truly random as you suggest.
However i've done a very large block of my random data output (i think it was 500mb?) and the
ratio of 1's to 0's was very close to 50%, maybe 48/52, but no farther than that. Random
binary data in theory should have a 50% 1 and 50% 0 ratio, and can have a 10% swing either
way.
Using a very small seed, and sloppy programming, it is true it will not qualify as a One Time
Pad. However used correctly, i see no reason it can't qualify.
Example, i have a working testing program that using the following key (test, for our
example, very over simplistic) can take this following paragraph and encrypt it to this
output:
SmCmDz1RAcqY8apKqGZAkUzroTrlplQULjoPdtP3T+6B5CU9rbccqRJivcWD
JTR7pVaAVU3EaaGXkp+PFRqJloOx+GueF4xEIvOg7S7U1tNuzOEJxYbKsXQQ
KtvRq8jBchUOS7k/TJDAZKXgYWwHYP5mhX8uzj2pNRM7yo/qfPY8Zgzql7Xf
7UuM
much more secure one, try if you dare.
SmALvEU6HNGBNQQYFKpYANmVPih7FvJqQiC9spft0WCLfu3Lysyzyy/4XzyY
Lb3aHdblUjw2PNeD7HNwuDdOUDGBocynLGZL7yzmHIljkYF7SpjIDThE4uaI
Ig6acGFzER7zfIYDy27kVCBZ9BDCnRM0TdCAbvF2oDvxjiJsn0nRj72+KggI
UO+K
This is using the prebuilt.c functions, integrating the 4 stages i mentioned in a previous
post. Should i have changed the key to something a bit more complex, oh say.. a specific music
file i have? Then you'd have to match the exact file in order to decrypt the OTP and the
semeir pair key.
But keep in mind, the OTP i made is more useful as a alternate parallel RNG's than they are
One Time Pads. But combined with a extra function or two, they are strong enough to be it,
where brute-forcing the key should be the only way to break it.
>I don't mean to hurt the feelings of the author of Semeir, and I don't mean to imply that he
>is dishonest, but it is important to tell people not to rely on a cipher of this kind for
some
>use where the cipher's failure could cause harm.
Quite agreed. Semeir is far from new though, it is merely unknown on the web as much as you
think, and has come a long ways.
If you feel it is not secure; merely because few testing papers have come forward to say so,
by all means stick to your other ciphers. However that doesn't mean you can't use it as an
experimental algorithm, and try it out.
(Besides, it's not backwards compatible anyways, each revision changes the way the cipher
works, so it's not a closed book yet, unlike AES and DES and Blowfish which are already
standardized)
Era
Semeir: 2.4.7 Released (SourceForge)
> However i've done a very large block of my random data output (i think it was 500mb?) and
the ratio of 1's to 0's was very close to 50%, maybe 48/52, but no farther than that. Random
binary data in theory should have a 50% 1 and 50% 0 ratio, and can have a 10% swing either
way.
Alas, if you got a 48/52 ratio on 500 megabytes of data, then your random number generator is
utterly awful; getting such a ratio out of a true random number generator is equivalent to
flipping a fair coin and getting heads ~4,617,869 times in a row[1]. Even a 49.99/50.01 split
would be proof that your RNG was broken (equivalent to ~120 heads in a row). I'm guessing you
just misremembered the numbers to post here, but this is the very simplest test of RNG
quality; if you haven't even done it carefully and documented the results, how can you
convince us to take on faith that the rest of your code is trustworthy? (Or even likely
enough to be trustworthy to be worth the time to look into more carefully?)
> Using a very small seed, and sloppy programming, it is true it will not qualify as a One
Time Pad. However used correctly, i see no reason it can't qualify.
Well, no. What you have is a stream cipher. There's no shame in writing a stream cipher
(ARC4 is one too, and block ciphers are commonly used as stream ciphers these days via tricks
like CTR mode), but doing that and then calling it a OTP will just destroy your credibility.
(Posting challenges on random internet threads with taunts like "if you dare" will also cause
people to put you on ignore without actually listening to your arguments any further.)
I'm sympathetic to your goals! But you don't seem to see that your current approach to
achieving them will just leave you exiled in the snake oil ghetto. If you want to convince
someone that your cipher is secure, you need to publish the design in a peer-reviewed journal,
not as code on the internet. To do this you need to prove that it is strong against various
existing attacks, ideally build up a reputation first by breaking existing ciphers, etc. Good
luck...
[1] Calculated with R: nbits <- 500 * 1000 * 1000 * 8; pbinom(0.48 * nbits, size=nbits,
prob=0.5, log.p=TRUE) / log(2). This is probably approximate, because it's pushing the limits
of machine precision and numerical stability pretty hard.
Semeir: 2.4.7 Released (SourceForge)
>Alas, if you got a 48/52 ratio on 500 megabytes of data, then your random number generator is
utterly awful; getting such a ratio out of a true random number generator is equivalent to
flipping a fair coin and getting heads ~4,617,869 times in a row[1]. Even a 49.99/50.01 split
would be proof that your RNG was broken (equivalent to ~120 heads in a row). I'm guessing you
just misremembered the numbers to post here, but this is the very simplest test of RNG
quality; if you haven't even done it carefully and documented the results, how can you
convince us to take on faith that the rest of your code is trustworthy? (Or even likely
enough to be trustworthy to be worth the time to look into more carefully?)
Yes i was recalling them from memory, and very badly at that. I've highly increased it's
reliability, and if you run the full length of the RNG, you will get 1:1 of 1's and 0's. Under
a smaller set it will be uneven, however even my small/medium size is hard to check entirely.
Here's my data on the output from a 9 blocksize, within 1% of being off.
9 - 10,625,324,586,456,701,730,816 Ints (38,654,705,664 -TeraBytes)
I did a output check on a 4Gig random data block, here's the results. (50% within 1/10000th
is pretty good, for such a small portion of it's total size.)
1's 17,179,831,574 - 49.999890540493652224540710449219%
0's 17,179,906,794 - 50.000109459506347775459289550781%
> Well, no. What you have is a stream cipher. There's no shame in writing a stream cipher
(ARC4 is one too, and block ciphers are commonly used as stream ciphers these days via tricks
like CTR mode), but doing that and then calling it a OTP will just destroy your credibility.
(Posting challenges on random internet threads with taunts like "if you dare" will also cause
people to put you on ignore without actually listening to your arguments any further.)
It's true it was originally a stream cipher, and continues to act that way when you tell it
to. But i tend to use it as a block cipher more, since there are certain features enabled when
using it this way, not available in the regular stream cipher. Two examples, first is random
placement of starting encryption and direction. Second is excellent cipher-feedback and
wrap-around for the whole block. (This makes the block and stream behave very differently,
even when using the same code)
It's only named OTP for it's secondary use, it's first and foremost being a alternate PRNG.
And nearly all functions rely on the cipher, i never claimed it was totally separate, it's
closely connected to the RNG, only it's interface and separated structure and slightly simpler
setup makes it different.
Are you suggesting i change my function names from their set to something else, based on a
Technicality?
(Note taken, i don't usually post challenges, nor do i expect someone to attempt it. I will
post no more 'challenges', however i will post example code with the appropriate password so
people can follow along.)
>I'm sympathetic to your goals! But you don't seem to see that your current approach to
achieving them will just leave you exiled in the snake oil ghetto. If you want to convince
someone that your cipher is secure, you need to publish the design in a peer-reviewed journal,
not as code on the internet. To do this you need to prove that it is strong against various
existing attacks, ideally build up a reputation first by breaking existing ciphers, etc. Good
luck...
Understood. However it will honestly be impractical/impossible to prove/disprove the code and
cipher, since it isn't locked to any bitsize, blocksize, and the internal encryption uses
between 8 and 12 bits. (It isn't a locked system yet, so it's currently version specific and
non-backwards compatible.)
I can however show at least in the RNG half of it is good enough (hopefully for cryptographic
uses as well), however it will probably take a month, and a few hundred megabytes to store the
data. And would anyone look at that specifically? (Would anyone even trust the data i give out
as genuine and not tweaked due to pride or anything? Or should i just create specific test
programs to show statistics of output data for them to follow?)
I'll look over current existing attacks, however 95% of them won't qualify merely by how the
cipher's built. Example, Frequency analysis kind of goes out the window when you go past a 2
byte blocksize. And there's a far higher chance that it being implemented wrong is a far
freater weakness than any cipher used. (Example, early in Netscape, it's SSL, was seeding the
time/date, allowing nearly any SSL at the time being broke within two minutes)
BTW, before i forget. If i am not mistaken, /dev/urandom does get random numbers from what's
going on in your system, but if it doesn't have enough data, it uses what's on hand, ready or
not, only the /dev/random was far more promising, however it sometimes took 10 minutes to get
1Meg. This is experience from a few years ago though, it's been a while since i tried that
again. (ex. dd if=/dev/random of=file bs=1024 count=1024)
Semeir: 2.4.7 Released (SourceForge)
>I tried to run some tests myself, but found that Semeir was painfully slow at generating
>random numbers -- "semeir-2.4.7/apps/simple -r /dev/stdin /dev/stdout
>this-is-my-super-secret-password | dd bs=4000 count=1000 of=random-data" took 30 minutes to
>execute, and that generates only 1/10 of the amount of data that the Dieharder recommends.
>/dev/urandom generates the same amount of data in under 2 seconds.
Note:
32: 3 keys, 8 keytype 12 minus 2 elements
$ dd if=/dev/zero of=d1 bs=4000 count=1000
1000+0 records in
1000+0 records out
4000000 bytes (4.0 MB) copied, 0.043 seconds, 93.0 MB/s
$ time ./simple.exe -e32 d1 d2
PASSWORD:
(make) / (make optimized)
real 0m33.827s / real 0m15.964s
user 0m32.671s / user 0m15.218s
sys 0m0.015s / sys 0m0.000s
Did i miss something? Thirty minutes??? I really fail to see what you mean by it's so slow.
(And i'm using truecrypt on my filesystem further slowing it down.) Honestly i haven't had the
chance to perfectly test the -r functionality; I have been forced to develop this the last two
years in CYGWIN environment, regardless, the timing is about the same for 4Mb.
>Yes, a proper OTP requires a unique stream of random data. So, for us to consider the
>encryption secure at all, you need to demonstrate that Semeir's random number generator is
>good. The burden of proof is on you, not us.
A while ago i had created a large series of output data from my cipher for diehard, and
tested it. Due to complications i could never try diehard2, which i really wanted to.
From tests the output from diehard were cryptic, but from what i could read, my cipher had
passed the RNG test, as it's failures were few and far between, no more common than expected
according to documentation.
Very soon i will go ahead and grab 1Gig of random data and individually test those 4Mb areas
and send it as txt.gz for everyone to see, should they even care. Will that satisfy you?
A much better output for OTP is to use the OTP protocol. Use the following. (apps/misc_test)
(much better suited for OTP, and defaults at 9 blocksize) Although slower than simple.
$ time cat d1 | ./otp.exe super-secret-key >out.txt
(make) / (make optimized)
real 0m59.120s / real 0m30.372s
user 0m58.623s / user 0m29.920s
sys 0m0.046s / sys 0m0.061s
>What are the benefits of Semeir that would make it a real contender to proven algorithms like
>AES? Wikipedia says that "AES is fast in both software and hardware, is relatively easy to
>implement, and requires little memory." Can you quantify in what ways Semeir outshines AES?
It is true, semeir requires more memory and resources to run (17k i believe per 8bit key).
But it's advantages at using larger blocksizes (512 bytes for example, perfect for HD
encryption) is there, where AES is a fixed blocksize. It would take a few thousand, maybe even
hundreds of thousands of rotations to get the same level as Semeir. Like all blocksizes, if
you have 1k of 0's, you WILL see a pattern after you hit the length, but with a larger
blocksize, you can break or mask it to a much harder level. Even 1 bit off changes the whole
output, instead of a 8-16 byte area that AES and other ciphers are fixed at.
Other strengths in the cipher, even IF you isolate the block, breaking it is pretty much a
brute force only method. It's randomly generated inside and out.
And if you don't trust the RNG or have a better one. Connect to the cipher and do the
following.
extern int (*rand2)(void) = your_perferred_random; //address only
extern int (*srand2)(int) = your_perferred_srandom;
Which will pull from your favorite function, when compiled correctly and never touch the
default one.
I have no preference towards ciphers, i'm not saying semeir is the perfect cipher, and i'm
not saying it's the best. It's an alternative and there are advantages, both in blocksize, the
bits per key. Random number generation, and plenty of other uses.
Please stop attacking the cipher and dis-crediting it without understanding it, since
obviously you did something wrong to get to your results. I will answer further questions;
however your claim of it taking 30minutes to get 4Mb is a complete lie. (unless you are
working on something a bit slower, say 10-50Mhz?, my system is a 1.2Ghz for the time stats).
Era
Semeir: 2.4.7 Released (SourceForge)
My command:
> semeir-2.4.7/apps/simple -r /dev/stdin /dev/stdout this-is-my-super-secret-password | dd
bs=4000 count=1000 of=random-data
Your command:
> time ./simple.exe -e32 d1 d2
> Did i miss something? Thirty minutes??? I really fail to see what you mean by it's so slow.
..
> since obviously you did something wrong to get to your results.
..
> your claim of it taking 30minutes to get 4Mb is a complete lie.
> (unless you are working on something a bit slower, say 10-50Mhz?, my system is a 1.2Ghz for
the time stats).
Yes, I really meant thirty minutes, and my results when comparing against /dev/urandom should
indicate that I'm not running on an underpowered machine. I don't resort to lying to prove a
point. I gave the exact command that I ran -- and you compared it against a different one.
Anyway, whatever. Good luck with your cipher.
Semeir: 2.4.7 Released (SourceForge)
>Yes, I really meant thirty minutes, and my results when comparing against /dev/urandom should
>indicate that I'm not running on an underpowered machine. I don't resort to lying to prove a
>point. I gave the exact command that I ran -- and you compared it against a different one.
>Anyway, whatever. Good luck with your cipher.
If it indeed did take thirty minutes, i am not sure why. Perhaps it's the interface on how
you incorporated the /dev/stdin that i don't follow. The only difference in the commands
internally to simple, isn't that much.
1) Blocksize of 32 bytes (in -r, that is the set blocksize, so -e32 -d32 and -r are all
identicle, except for outputting to a file instead of stdout)
//taken from simple.c
if (strncmp (argv[1], "-r", 2) == 0)
{
crypt = ENCRYPT;
BLOCK = 32;
c = rand_out = 2;
}
2) use a file instead of a stream, so we don't calculate hardly anything outside of the
actual encryption.
I do request you try results again against a file, and see if it's still 30 minutes. Also,
try using 'make optimized' in both /src and /apps, which will cut computations in half.
Era
Semeir: 2.4.7 Released (SourceForge)
>1) Blocksize of 32 bytes (in -r, that is the set blocksize, so -e32 -d32 and -r are all
>identicle, except for outputting to a file instead of stdout)
Correction, i must apologize. i looked at my code once more and noticed this.
for (a = 0; a < 32 / sizeof (int); a++)
SRAND2 (((int *) buffer)[a]);
Honestly i forgot that was there. SRAND2 is actually (*srand2)(int), upon running it resets
all the internal random data. This explains the 30 minutes. I haven't had a chance to try out
those functions in a few years :(
Use the OTP function instead for your tests. Even if it takes all zero's, it will give you a
random stream. Should take you 30 seconds per 4Mb, as my tests show.
/apps/misc_tests/otp.c
dd if=dev/zero bs=1M count=16 | ./otp just_a_long_password >outfile.rand
Era
Diehard Tests - PRNG
I've gone ahead and made a 1Gig file, and divided it into 12Mb parts. Then put each of those
through diehard (modified to default a specific file). This is the outputting i get, that you
can look over, using 'ultra_secret_password'.
http://www.geocities.com/rtcvb32/zips/dh.tbz2.zip (Geocities only wants zips for some reason,
the straight zip is 900k, rather than 303k)
Each file is labeled dh_??.txt where ?? is 0-84, for each 12Mb area.
Please review and give me your comments on this. You can duplicate the code if you choose. I
ended up doing the following
dd if=otp.out of=12m bs=1M skip=0 count=12
diehard >dh_0.txt
...
dd if=otp.out of=12m bs=1M skip=1008 count=12
diehard >dh_84.txt
Etc.
I have supplied the Diehard tests, which coveres the OTP and PRNG. I can repeat with a
hundred thousand other keys if you like and combine them into a new file, however i'm running
low on geocities, so i'd have to find another place to post the results.
What other tests do you recommend for the RNG and the cipher?
Era