Cryptography-Digest Digest #644, Volume #14 Mon, 18 Jun 01 20:13:00 EDT
Contents:
Re: Cypherus encryption software ("Tom St Denis")
Re: Single-cycle sbox question ("Henrick Hellstr�m")
Re: Single-cycle sbox question ("Tom St Denis")
Re: Counter mode, the better way to do it? ("Joseph Ashwood")
Re: Cypherus encryption software ("Paul Pires")
Re: Counter mode, the better way to do it? ("Tom St Denis")
Re: "Stupid" questions... (Sam Yorko)
Re: Cypherus encryption software ("Joseph Ashwood")
Re: "Stupid" questions... ("Tom St Denis")
Re: Single-cycle sbox question ("Henrick Hellstr�m")
Re: Cypherus encryption software ("Tom St Denis")
Re: Single-cycle sbox question ("Tom St Denis")
Re: Single-cycle sbox question ("Henrick Hellstr�m")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Cypherus encryption software
Date: Mon, 18 Jun 2001 22:57:21 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:u3cbkiE#AHA.184@cpmsnbbsa07...
> A bit of commentary.
>
> I have quickly reviewed the cypherus site. It does not seem to be the
> standard snake-oil. It uses DH to exchange keys and Blowfish for
encryption,
> so it's got decent foundations. However it utilizes only a password for
> protection, which is likely to be it's achilles heel. Also it is
apparently
> completely non-standards based. The errors on the page seem to be of the
> sort where a technical writer wrote it, as opposed to having an engineer
> write it. They give no information about how the keys are stored, or any
> certification of keys, this is slightly worrisome, but also because the
page
> does not seem to have been written by an engineer may not reflect the
actual
> state of the system. It's still worrisome however.
>
> I believe that there is sufficient reason to believe that this is not pure
> snake-oil. I also believe that it is not as secure as the benchmark of
PGP.
Yes, just because it uses DH or Blowfish doesn't automagically make it
secure.
Being closed source does make it suspect though. For example, I trust RSA
todo a closed source crypto kit. their jobs depend on it. What happens if
el-dorko makes a bad program? He will probably blame the user.
Tom
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Tue, 19 Jun 2001 00:59:37 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:uHuX6.157931$[EMAIL PROTECTED]...
>
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> news:9glsci$c5h$[EMAIL PROTECTED]...
> > Sure you can. But in my opinion you are encouraged to do so in C.
>
> Says you. My mentor always made me write clearly indented code with
> comments and clever variable names.
Good. Unfortunately, most C programmers did not have your mentor, as it
seems. ;-)
> > I suggest that you should write either:
> >
> > Let a, b, c, d, e, f, g be such that a=b=c=d=e=f=g=0
>
> I though we were discussing programming langauges.
I was in that case discussing pseudo code. Cf HAC for some examples of well
written pseudo code with lots of english plain text.
[snip]
> In standard pascal you can write
>
> function myfunction: real;
> var
> c, b:integer;
>
> function someother(b:integer): integer;
> var a, c: integer;
> begin
> a := 3;
> for c := 0 to b do a := a + a;
> someother := a;
> end;
>
> begin
> b := 0;
> for c := 0 to 34 do
> b := b + someother(c+b);
> myfunction := real(b);
> end;
>
> Tell me that's good coding style !!!
It's not, because that code is not indented according to the standard
recommendations. You should, like most Pascal programmers in fact would,
write the same (obviously non-optimized) algorithm as:
function MyFunction: Real;
var
c, b: Integer;
function SomeOther(SomeArg: Integer): Integer;
var
a, i: Integer;
begin
a := 3;
for i := 0 to SomeArg do
a := a + a;
SomeOther := a;
end;
begin
b := 0;
for c := 0 to 34 do
b := b + SomeOther(c+b);
MyFunction := b;
end;
Typecasting is not allowed in Standard Pascal. Furthermore you are allowed
to assign an integer value to a real, but not the converse in which case you
have to use the Round function.
Non-reserved words are usually capitalized for readability. The use of
single letter variables is discouraged except when they have no meaning
outside of the context. Loop variables that are not accessed inside the loop
or are only used to index arrays are named i, j, k etc. Local variables in
sub-procedures should not have the same name as variables in the surrounding
procedure or environment, but that is a matter of opinion even amongst
educated programmers.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Mon, 18 Jun 2001 23:03:58 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9gm12o$jiq$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:uHuX6.157931$[EMAIL PROTECTED]...
> >
> > "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> > news:9glsci$c5h$[EMAIL PROTECTED]...
> > > Sure you can. But in my opinion you are encouraged to do so in C.
> >
> > Says you. My mentor always made me write clearly indented code with
> > comments and clever variable names.
>
> Good. Unfortunately, most C programmers did not have your mentor, as it
> seems. ;-)
Maybe you're a cynic. I know alot of bad coders and alot of good coders.
Programming in C is not the cause or catalyst.
>
> > > I suggest that you should write either:
> > >
> > > Let a, b, c, d, e, f, g be such that a=b=c=d=e=f=g=0
> >
> > I though we were discussing programming langauges.
>
> I was in that case discussing pseudo code. Cf HAC for some examples of
well
> written pseudo code with lots of english plain text.
Or TAOCP.
>
> It's not, because that code is not indented according to the standard
> recommendations. You should, like most Pascal programmers in fact would,
> write the same (obviously non-optimized) algorithm as:
<snip>
You're missing my point. I was trying to show that I could write sloppy
Pascal code [actually I haven't touched pascal since my Grade 11 comp-sci
[which I did in grade 10 btw]].
I can write beautifully clear C code just as easily as Pascal code. I can
write horribly unclear C code just as easily as Pascal code.
I agree that there are many bad coders out there [i.e OOP'ers] but for the
most part there is alot of good code.
My Biquad audio filters for example is based on a simpler piece of C code I
found...
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Date: Mon, 18 Jun 2001 15:59:23 -0700
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Would you in general recommend this (say MD5(key,count) in CTR mode)
> versus Rijndael in CTR mode? Also, which would be cleaper on CPU churn?
I wouldn't. The MD5 state machine is has not been proven complete. In this
case it means that given a key, it is not known whether or not all possible
output values can be reached simply by incrementing the counter. the same is
not true for Rijndael, which by it's invertibility property is complete.
However the MD5 statemachine has a maximum path length that is far greater
than Rijndael's.
I believe that in this case you will sacrifice a small amount of security,
but if you need to go for longer than 2^64 you will begin to see security
swing into the favor of the MD5 construct, simply by the fact that the
state is still pseudo-random while the Rijndael output space is steadily
decreasing.
Also because of the design of MD5 the maximum effective key is 128-bits,
this can be worrisome for some conditions, but for most is not an issue.
Comparing this to Rijndael which was designed to have a (accepted) maximum
key size of 256.
I think tjhe most worrisome thing, and what finally sways my opinion enough
to judge is the relatively minor attack on MD5. For use as a hash it is not
overly significant, but it is enough to question the inability of the
attacker to count in MD5 with unknown (or partially unknown) preimage.
Given the doubt that this creates I would be inclined to recommend not using
counter mode MD5 when counter mode Rijndael is available.
Joe
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Cypherus encryption software
Date: Mon, 18 Jun 2001 16:19:18 -0700
A google search on Andrew Palumbo yeilds similar reasons
to doubt that he is in search of reptiles to lubricate.
He does appear to have a connection to comp-sci but in
a different feild (Or he's a Lacross player) Assuming this is he,
it dosn't look like he's a candidate for spam-miester to me. Maybe
sometimes the toast does land jelly-side up.
Paul
Joseph Ashwood <[EMAIL PROTECTED]> wrote in message news:u3cbkiE#AHA.184@cpmsnbbsa07...
> A bit of commentary.
>
> I have quickly reviewed the cypherus site. It does not seem to be the
> standard snake-oil. It uses DH to exchange keys and Blowfish for encryption,
> so it's got decent foundations. However it utilizes only a password for
> protection, which is likely to be it's achilles heel. Also it is apparently
> completely non-standards based. The errors on the page seem to be of the
> sort where a technical writer wrote it, as opposed to having an engineer
> write it. They give no information about how the keys are stored, or any
> certification of keys, this is slightly worrisome, but also because the page
> does not seem to have been written by an engineer may not reflect the actual
> state of the system. It's still worrisome however.
>
> I believe that there is sufficient reason to believe that this is not pure
> snake-oil. I also believe that it is not as secure as the benchmark of PGP.
> Joe
>
> "Andrew Palumbo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hey guys, I've been lurking the group for a while, but this is my
> > first post.
> >
> > I just wanted to let you guys know about a really neat encryption
> > program I found, Cypherus. It can encrypt all your files, and has
> > plug-ins for most email clients, so you can send private emails, too.
> > It looks like it uses Blowfish for the encryption and something with
> > Diffie-hellman for the public/private key stuff.
> >
> > They say it's supposed to be alot easier to use than PGP, and after
> > trying it, I'm prone to agree. It runs on both the Windows 95/98/ME
> > tree and Windows NT/2000.
> >
> > You can check out the website, here:
> >
> > http://www.cypherus.com
> >
> > Or, you can just download the 30-day trial:
> >
> > http://www.cypherus.com/downloadeval.php
> >
> > Take care!
> > Andrew
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Date: Mon, 18 Jun 2001 23:23:21 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:eYgg$tE#AHA.302@cpmsnbbsa07...
> "Julian Morrison" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Would you in general recommend this (say MD5(key,count) in CTR mode)
> > versus Rijndael in CTR mode? Also, which would be cleaper on CPU churn?
>
> I wouldn't. The MD5 state machine is has not been proven complete. In this
> case it means that given a key, it is not known whether or not all
possible
> output values can be reached simply by incrementing the counter. the same
is
> not true for Rijndael, which by it's invertibility property is complete.
Yes, but as long as the # of outputs is sufficiently large it doesn't
matter.
> However the MD5 statemachine has a maximum path length that is far greater
> than Rijndael's.
>
> I believe that in this case you will sacrifice a small amount of security,
> but if you need to go for longer than 2^64 you will begin to see security
> swing into the favor of the MD5 construct, simply by the fact that the
> state is still pseudo-random while the Rijndael output space is steadily
> decreasing.
>
> Also because of the design of MD5 the maximum effective key is 128-bits,
> this can be worrisome for some conditions, but for most is not an issue.
> Comparing this to Rijndael which was designed to have a (accepted) maximum
> key size of 256.
This is not true. You can use a 448 bit private seed with a 64 bit counter
and do a single compression [no MD5 MD-Strengthening]. The effect key size
would be 448 bits in this case.
> I think tjhe most worrisome thing, and what finally sways my opinion
enough
> to judge is the relatively minor attack on MD5. For use as a hash it is
not
> overly significant, but it is enough to question the inability of the
> attacker to count in MD5 with unknown (or partially unknown) preimage.
>
> Given the doubt that this creates I would be inclined to recommend not
using
> counter mode MD5 when counter mode Rijndael is available.
Um I am not convinced that MD5 is a poorer choice. Of course I would use
SHA-1 anyways :-)
Tom
------------------------------
From: Sam Yorko <[EMAIL PROTECTED]>
Subject: Re: "Stupid" questions...
Date: Mon, 18 Jun 2001 16:33:32 -0800
Tom St Denis wrote:
>
> To the sci.crypt group: Sorry for asking stupid questions so often... Just
> trying to make sure I understand the vocabulary first!
>
> Tom
Just keep asking; what may seem stupid to you is wildly fascinating to
me right now, since I'm catching up to speed on sci.crypt.
Just a note: I started monitering sci.crypt a few weeks ago, and the
news server at the time was archiving the last five months of posts.
I've managed to work my way through all of them to here, and I have only
about 1135 more posts to wade through to catch up. I've noticed one
thing: the same basic questions tend to get asked over and over again,
with a very annoying frequency. This effect has been remarked upon. My
only comment is that it's a characteristic of this medium, and nothing
will get rid of it. As an example, I'm just getting started on this,
and I had the same questions that anybody else had. However, I'm not
going to force anybody to wade through the 16,000 messages (no, that is
>not< an exaggeration; I'm currently showing 15,388 messages in sci.crypt) to find the
>answer they way I did.
It's like the message that pops up about once a week on comp.music.midi
asking for a program to convert .wav files to midi files. It's
currently impossible to do, but we get really tired of answering that
over and over again. But, hey, I do get a lot of good out of the
newsgroups, so I take what I can use and leave the rest alone...
Sam
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cypherus encryption software
Date: Mon, 18 Jun 2001 16:24:06 -0700
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:lHvX6.158289$[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
> news:u3cbkiE#AHA.184@cpmsnbbsa07...
> > A bit of commentary.
> >
> > I have quickly reviewed the cypherus site. It does not seem to be the
> > standard snake-oil. It uses DH to exchange keys and Blowfish for
> encryption,
> > so it's got decent foundations. However it utilizes only a password for
> > protection, which is likely to be it's achilles heel. Also it is
> apparently
> > completely non-standards based. The errors on the page seem to be of the
> > sort where a technical writer wrote it, as opposed to having an engineer
> > write it. They give no information about how the keys are stored, or any
> > certification of keys, this is slightly worrisome, but also because the
> page
> > does not seem to have been written by an engineer may not reflect the
> actual
> > state of the system. It's still worrisome however.
> >
> > I believe that there is sufficient reason to believe that this is not
pure
> > snake-oil. I also believe that it is not as secure as the benchmark of
> PGP.
>
> Yes, just because it uses DH or Blowfish doesn't automagically make it
> secure.
Correct, but it also means that it has a chance of being secure. Like I said
I don't think this is pure snake-oil, I think this is a (at least
semi-)honest attempt at security, but I doubt it's as secure as PGP (or
several other well known products).
> Being closed source does make it suspect though.
I agree, it certainly makes it suspect to use, but your average user will
have to trust someone even if it is open source (i.e. take a look at the
linux kernel source code, you will probably have to trust someone that it
works).
> For example, I trust RSA
> todo a closed source crypto kit. their jobs depend on it.
And the job of the person selling this isn't on the line? You trust RSA
because they have a reputation of quality, where this person/people have no
reputation built up.
> What happens if
> el-dorko makes a bad program? He will probably blame the user.
Can't debate that, I've seen it waaaaay too many times.
I still don't think it's pure snake-oil, but I don't think it's highly
secure either. I still recommend PGP, if it's for non-commercial use it's
free, and for commercial use it's relatively cheap.
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "Stupid" questions...
Date: Mon, 18 Jun 2001 23:39:03 GMT
"Sam Yorko" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > To the sci.crypt group: Sorry for asking stupid questions so often...
Just
> > trying to make sure I understand the vocabulary first!
> >
> > Tom
>
> Just keep asking; what may seem stupid to you is wildly fascinating to
> me right now, since I'm catching up to speed on sci.crypt.
Learning by proxy. Eh, why not.
> Just a note: I started monitering sci.crypt a few weeks ago, and the
> news server at the time was archiving the last five months of posts.
> I've managed to work my way through all of them to here, and I have only
> about 1135 more posts to wade through to catch up. I've noticed one
> thing: the same basic questions tend to get asked over and over again,
> with a very annoying frequency. This effect has been remarked upon. My
> only comment is that it's a characteristic of this medium, and nothing
> will get rid of it. As an example, I'm just getting started on this,
> and I had the same questions that anybody else had. However, I'm not
> going to force anybody to wade through the 16,000 messages (no, that is
> >not< an exaggeration; I'm currently showing 15,388 messages in sci.crypt)
to find the answer they way I did.
> It's like the message that pops up about once a week on comp.music.midi
> asking for a program to convert .wav files to midi files. It's
> currently impossible to do, but we get really tired of answering that
> over and over again. But, hey, I do get a lot of good out of the
> newsgroups, so I take what I can use and leave the rest alone...
Here's a tip I use. When you start a new group delete all current posts and
pretend like its new. Sit back and read the posts for a bit [new posts] so
you don't get flooded and so you can figure out what is topical.
Going through 15,000 messages will be highly unproductive.
Tom
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Tue, 19 Jun 2001 01:41:42 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:yNvX6.158341$[EMAIL PROTECTED]...
> You're missing my point. I was trying to show that I could write sloppy
> Pascal code [actually I haven't touched pascal since my Grade 11 comp-sci
> [which I did in grade 10 btw]].
Yes, anyone can write sloppy Pascal code, but for some reason practically no
Pascal programmers write unindented code, and that was the major problem
with your example. It became perfectly readable once properly indented.
The problem I have with reading C code is all of those multiple assignments
sometimes mixed up with post-/pre- in/decrements. For example, I found this
line in the discrete fourier transform implementation in NISTs RNG test
library:
ch[(t5+=(ido<<1))-1]=cc[t3]-cc[t4];
In Pascal you would have to write that in two disjoint statements, like
this:
t5 := t5 + (ido * 2);
ch[t5-1] := cc[t3] - cc[t4];
The logic is IMO much clearer in the Pascal version, because you don't have
to look twice to understand the order of execution.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Cypherus encryption software
Date: Mon, 18 Jun 2001 23:41:27 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:urGXQ6E#AHA.162@cpmsnbbsa07...
> > Yes, just because it uses DH or Blowfish doesn't automagically make it
> > secure.
>
> Correct, but it also means that it has a chance of being secure. Like I
said
> I don't think this is pure snake-oil, I think this is a (at least
> semi-)honest attempt at security, but I doubt it's as secure as PGP (or
> several other well known products).
I would argue using "DH" and "Blowfish" is a moot point. I could write a
new cipher in the next 10 mins that is most likely "resilient enough" to any
attack imaginable. Often how you use the tools are more important than the
tools themselves.
> > Being closed source does make it suspect though.
>
> I agree, it certainly makes it suspect to use, but your average user will
> have to trust someone even if it is open source (i.e. take a look at the
> linux kernel source code, you will probably have to trust someone that it
> works).
Yes this is true. However, Id rather trust someone with history.
> > For example, I trust RSA
> > todo a closed source crypto kit. their jobs depend on it.
>
> And the job of the person selling this isn't on the line? You trust RSA
> because they have a reputation of quality, where this person/people have
no
> reputation built up.
>
> > What happens if
> > el-dorko makes a bad program? He will probably blame the user.
>
> Can't debate that, I've seen it waaaaay too many times.
>
> I still don't think it's pure snake-oil, but I don't think it's highly
> secure either. I still recommend PGP, if it's for non-commercial use it's
> free, and for commercial use it's relatively cheap.
The problem is how can you recommend PGP blindly? Unless we are only
talking about email
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Mon, 18 Jun 2001 23:44:45 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9gm3hj$n6v$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:yNvX6.158341$[EMAIL PROTECTED]...
> > You're missing my point. I was trying to show that I could write sloppy
> > Pascal code [actually I haven't touched pascal since my Grade 11
comp-sci
> > [which I did in grade 10 btw]].
>
> Yes, anyone can write sloppy Pascal code, but for some reason practically
no
> Pascal programmers write unindented code, and that was the major problem
> with your example. It became perfectly readable once properly indented.
>
> The problem I have with reading C code is all of those multiple
assignments
> sometimes mixed up with post-/pre- in/decrements. For example, I found
this
> line in the discrete fourier transform implementation in NISTs RNG test
> library:
>
> ch[(t5+=(ido<<1))-1]=cc[t3]-cc[t4];
I would never write this. Primarily because t5 could overflow.
I would most likely do
t5 += (ido<<1) - 1;
ch[t5] = cc[t3] - cc[t4];
> In Pascal you would have to write that in two disjoint statements, like
> this:
>
> t5 := t5 + (ido * 2);
> ch[t5-1] := cc[t3] - cc[t4];
Amazingly this looks like my C code.
> The logic is IMO much clearer in the Pascal version, because you don't
have
> to look twice to understand the order of execution.
I find your argument very narrow minded and moot. You generalize that all
code once written in Pascal is perfectly readable and cute code. But I
contest that bad code can be written in either lang.
Tom
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Tue, 19 Jun 2001 01:55:02 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:NnwX6.158659$[EMAIL PROTECTED]...
> I find your argument very narrow minded and moot. You generalize that all
> code once written in Pascal is perfectly readable and cute code. But I
> contest that bad code can be written in either lang.
I argue that the absence of some syntactic elements in Pascal makes it
impossible for bad coders to write particular kinds of extremely bad code
even NIST programmers write in C. According to my experience less effort is
therefore required to clean up bad Pascal code than to clean up bad C code.
Other people might have other experiences.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
