Cryptography-Digest Digest #297, Volume #13 Sat, 9 Dec 00 10:13:00 EST
Contents:
Re: [Question] Generation of random keys (Bryan Olson)
Non-linear block chaining and MAC (Mok-Kong Shen)
Custom Encryption Algorithm ("Phil Massimi")
Re: [Question] Generation of random keys (David Schwartz)
Re: Custom Encryption Algorithm (David Schwartz)
Re: document signing, XML canonicalization and why EDDF is a better choice (denis
bider)
Re: document signing, XML canonicalization and why EDDF is a better choice (denis
bider)
Any info on FFT-hashes? ("Dmitry V. Girenko")
Re: What's better CAST in PGP or Blowfish 128bit? ("Sam Simpson")
Re: What's better CAST in PGP or Blowfish 128bit? (Tom St Denis)
Re: What's better CAST in PGP or Blowfish 128bit? (Tom St Denis)
Re: document signing, XML canonicalization and why EDDF is a better choice (Tom St
Denis)
Re: ASM code public/private key cryptography source code (Tom St Denis)
Re: Custom Encryption Algorithm (Tom St Denis)
Re: document signing, XML canonicalization and why EDDF is a better choice (PB)
Re: document signing, XML canonicalization and why EDDF is a better choice (denis
bider)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Sat, 09 Dec 2000 09:06:58 GMT
David Schwartz wrote:
> By many definitions, a correlated stream is simply not random,
> whereas a biased stream can be random.
Perhaps it would help if you stated a mathematically respectable
definition and listed a good reference.
> So converting a
> correlated stream into a biased stream _is_ an incrase in
> randomness, by the most common definitions.
In cryptology, by far the most accepted meaning of "random"
is in the sense of entropy as definied by Shannon.
> However, I personally prefer to treat the words "random"
> and "unpredictable" as synonymous. The extent to which
> something is random (with respect to something) is the
> extent to which that something can't predict it.
Has a respectable definition of "unpredictable" appeared?
My off-hand interpretation would contradict your claim,
since if string y is the output of a known algorithm
on input x, then we can predict y correctly whenever we
can predict x correctly.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Non-linear block chaining and MAC
Date: Sat, 09 Dec 2000 10:18:08 +0100
It is known that CBC can provide a MAC. The non-linear block
chaining method that I proposed previously (see the threads
'Nonlinear block chaining and whitening' of 25 Jul and
'A poorman's cipher' of 18 Nov):
S:=IV;
do i=1 to n
U:=P[i] + S (mod 2^m);
C[i]:=E(K,U);
S:=S + f(P[i],C[i]) (mod 2^m);
od;
where E is the block cipher of size m bits with key K, IV
is the initializaiton vector, P[1..n] and C[1..n] are the
plaintext and ciphertext respectively and f(p,c) is a
arbitrarily chosen non-linear function, e.g. p^2+c^2 or p*c,
can also be provided with a MAC. We can namely append to the
result C[1..n] thus obtained two more blocks E(K,IV) and
E(K,S), where S is the value at exit of the above do-loop.
(We have preferred in the given alogrithm modular addition
to XOR, which could also be used.)
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Phil Massimi" <[EMAIL PROTECTED]>
Subject: Custom Encryption Algorithm
Date: Thu, 07 Dec 2000 01:35:14 GMT
Hi. :)
Ok, I'm no expert in cryptography... I'm a simple software developer.
However, I'm beginning to take an interest in it. I put together my first
encryption algorithm for a little custom made chat program of mine, and
wondered if anybody would be interested in trying to crack it. There are no
keys... simply a formula to encrypt a text string, and another formula to
convert it back to text again.
If you get it, I'd be very interested to know what hardware/software you
used to crack it, and how long it took you to get through it. Please send
any correspondence to [EMAIL PROTECTED] if you don't mind.
Enjoy. :) And thanks! Here's a sample message.
0010201313000711400110710511001009221021911110020
00171107061101111113113019010401111923230310110020
18111130314712111601412711130171111121121007011011
17700101012202012011001091300110353201040101019130
11302303119084111111302021140461103022301620101111
11010051200411170901813441913191011711121310110301
17713011112010195000210121714400311001000910000310
18101111110060121313135011001290211710143820370461
71300100110321101011310530011024112401110371011121
05110121111001110121421019073131101010109103211110
11803611710314171106211111111151371613201010202036
13131111119707017126653103312002901039607201191110
51011196153110714052450098260170948924102310710014
72129012920101173119091091503341619210431012171502
410332399301319421369610305224206391921273200891
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Sat, 09 Dec 2000 02:09:35 -0800
Bryan Olson wrote:
>
> David Schwartz wrote:
>
> > By many definitions, a correlated stream is simply not random,
> > whereas a biased stream can be random.
>
> Perhaps it would help if you stated a mathematically respectable
> definition and listed a good reference.
There was another thread all about this. Several different definitions
of random were presented, and the majority of them would not extend the
concept 'random' to include correlated streams.
> > So converting a
> > correlated stream into a biased stream _is_ an incrase in
> > randomness, by the most common definitions.
>
> In cryptology, by far the most accepted meaning of "random"
> is in the sense of entropy as definied by Shannon.
This would mean that there's no such thing as a PRNG.
> > However, I personally prefer to treat the words "random"
> > and "unpredictable" as synonymous. The extent to which
> > something is random (with respect to something) is the
> > extent to which that something can't predict it.
>
> Has a respectable definition of "unpredictable" appeared?
Unfortunately, it's about as fuzzy as 'random' is. You have to suppose
some hypothetical predictor with specific capabilities. Then you measure
how hard it is for the predicter to predict.
One simple examples of such a 'measure of unpredictability' could be
how many guesses the predicter needs before he or she has a 50% chance
of having guessed the correct result. So, to a predicter with no access
to or knowledge of a coin, a single flip has an unpredictability of '1'.
The output of a PRNG seeded with a 64-bit hash has an unpredictability
of about 2^32 regardless of how long the output is.
Note that to do this, you must specify a predictor and state what his
capabilities are. If, for example, you feed into an algorithm noise from
computer's CPU usage, you might posit one attacker who could run a
process on that machine (and thus to some extent control and measure
that) and you might posit another who couldn't access that machine. One
predictor might be better able to predict the resulsts, and thus to him
they aren't as unpredictable.
This seems to me to be simply common sense.
> My off-hand interpretation would contradict your claim,
> since if string y is the output of a known algorithm
> on input x, then we can predict y correctly whenever we
> can predict x correctly.
Well, you either have to accept that the algorithm has some input (that
may or may not be predictable) or you have to assume that some portion
of the algorithm is unknown to the something with respect to which you
are considering it random. Otherwise, of course, the output is entirely
predictable.
In the interest of keeping things simple, I prefer to consider the
'algorithm' to be known to the 'attacker' (by definition, the
'algorithm' is whatever the attacker knows). Call whatever isn't known
to the 'attacker' to be the 'key', 'input', or 'seed'. This is
consistent with common practice in encryption where whatever isn't known
to a supposed interpcepted is considered part of the 'key'.
Now, if you assume the algorithm is what's known to the attacker and
that the algorithm must be deterministic, there are at most as many
possible outputs as there are possible inputs. And thus the output is
(in the sense described above) always at least as predictable as the
input.
As I said, an algorithm can produce anything except unpredictability.
By most definitions of randomness, an algorithm can produce randomness.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 09 Dec 2000 02:10:57 -0800
Phil Massimi wrote:
> Ok, I'm no expert in cryptography... I'm a simple software developer.
> However, I'm beginning to take an interest in it. I put together my first
> encryption algorithm for a little custom made chat program of mine, and
> wondered if anybody would be interested in trying to crack it. There are no
> keys... simply a formula to encrypt a text string, and another formula to
> convert it back to text again.
If there's no key, there's nothing to crack. One cracks an encryption
algorithm by finding the key.
DS
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 10:47:22 GMT
On Fri, 08 Dec 2000 20:50:06 -0800, Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>Ok, so XML is not perfect. Do you really think the world is going
>to switch to your document format just because it is no worse
>than XML and maybe even slightly better for some narrow particular
>purpose?
The words "narrow particular purpose" worry me somewhat. What format
are your contracts going to be in 10 years? I dare say it will be a
standardized format. The reasoning is as follows:
- In order to have a society that relies on electronic signatures,
you need everyone to carry around a Personal Security Device. You
can't ever trust a PC to do your signatures.
- The PSD won't be creating documents - it will just show them to you
for authorization, and then it will sign them.
- The PSD will have to be able to parse input documents in order to
show them to you.
Hence, a standardized data format will ultimately be necessary. Before
everyone has a PSD, electronic signatures will not flourish. And
before there is a standardized format, PSD's will be useless. You see,
we will NEED a standardized format for electronic signatures.
And I dare say, this will eventually be the same format that is used
for everything else, too. Electronic signing will be ubiquitous; why
would you want to have one format for data processing and another one
for electronic signing? You need one for both.
XML has two problems that I think will turn out to be major headaches:
- It is difficult to convert a document to canonical form.
- It is difficult to include binary data in a document.
What I fear is the following scenario:
- With all the hype around XML, everybody starts to use it.
- Suddenly, we start discovering it's got these major problems that
we never thought are very significant.
- In a while, these problems start bugging us more and more, and we
design all these patches for XML that should fix these problems. (We
already have some of these patches in development - like the "XML
canonical form" draft)
- These patches don't really fix anything in the long term, they just
add to the confusion.
- So, several years from now, someone in the research community
springs up and says: "I've got this great now format that solves all
these problems we have with XML!"
- And people say, well, maybe it's worth it - we're sick of these
problems with XML, let's try it.
- And there is a standardization effort, and there is a transition
period, and twenty years go by.
- And thirty years from now everyone uses EDDF.
XML is a fine specification as it is, but I think it is not suitable
What I fear is that we will have to learn this the hard way.
Transition from XML to EDDF is extremely simple. In every program that
uses XML, you plug out the XML parser, and you plug in the EDDF
parser. That is, literally, about it.
Of course, several features still need to be added to the EDDF parser
- like schema validation, for instance. But this general idea will
work if there are enough people to grok it.
>> The reasons behind a judgement that DER is "backwards" would probably
>> have something to do with the fact that XML can be read in a text
>> editor; and DER cannot. And that XML can be created with a text
>> editor; while DER cannot.
>
>Also, XML has a simple syntax that is easy to understand and parse.
>ASN.1 DER is not all that hard, but it is a lot more complicated
>than it needs to be for the purposes for which it is commonly used.
>Programmers dislike it. As a results, systems that use ASN.1
>commonly have ASN.1-related bugs.
If you have worked with XML, you probably also know that the same
statement applies for systems that use it.
XML *seems* to have a simple syntax, but that is primarily an
illusion. Ever tried writing an XML parser? First you say, whoa, this
is going to be a piece of cake. Then you say, whoa, there's more to
it. Then you say, whoa, this is too much!
That is, in a way, what happened to me.
With DER, there is no false impression that it is simpler that it is.
It is as simple as it is. I found DER to be very straightforward to
implement.
On, to top it off: if you're using any decent programming language,
you won't have to write a parser, because I've done it already. It is
ANSI C, it is portable to almost any platform, and is completely free
to use. Now beat that. :-)
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 10:49:39 GMT
On Sat, 09 Dec 2000 00:06:41 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>> There is a candidate for a universal data format, however, and its
>> name is XML. But when it comes to digital signature and signature
>
>I would argue PGP is rather standard for txt msgs.
Hello Tom - please see the other message I just posted. I think it
should explain what I meant with a universal data format, and once you
read that message, I think it should be obvious why text messages are
irrelevant with those considerations in mind.
Think long term.
Regards,
denis
------------------------------
From: "Dmitry V. Girenko" <[EMAIL PROTECTED]>
Subject: Any info on FFT-hashes?
Date: Sat, 9 Dec 2000 14:38:49 +0300
I'm trying to investigate some aspects of cracking A3A8 hash function. I use
approach proposed by the ISAAC security research group and SDA, but it seems
that there are some problems with it. I need some information about FFT-like
hashes (construction, features, etc..) to investigate this problem futher.
Can anyone help me?
--
Dmitry V. Girenko
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Sat, 9 Dec 2000 11:56:22 -0000
Well said.....We (the crypto-savvy public) complain when crypto isn't
available in products (or employs crap algorithms), so surely it's stupid to
reply in the manned that Tom has.
People shouldn't have to know everything about what algorithms exist and so
on - they should simply be able to ask this simple question in this group
and get a civil 'best practice' answer. Crypto is a lot to us but, as
noname says, it's just a black box with input and output.
Or am I hopelessly optimistic?
Sam
"Noname" <[EMAIL PROTECTED]> wrote in message news:90r9q8$mqj$[EMAIL PROTECTED]...
> Yes, I need to learn and therefore I'm here:o)). Is it a problem? I cannot
> know everything:o)). I am coder and I need to include encryption into my
> product.
> And that's all. So for me is crypting only algorithm with input and
output.
>
> Tom St Denis <[EMAIL PROTECTED]> píše v diskusním
> příspěvku:90kblp$b3o$[EMAIL PROTECTED]
> > In article <90jlus$2rpc$[EMAIL PROTECTED]>,
> > "Noname" <[EMAIL PROTECTED]> wrote:
> > > I need strong algorithm and it can be slow in encrypt/decrypt. I need
> > the
> > > best:o).
> >
> > You need to learn about crypto is what you need.
> >
> > Tom
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
>
>
>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Sat, 09 Dec 2000 14:32:34 GMT
In article <90r9q8$mqj$[EMAIL PROTECTED]>,
"Noname" <[EMAIL PROTECTED]> wrote:
> Yes, I need to learn and therefore I'm here:o)). Is it a problem? I
cannot
> know everything:o)). I am coder and I need to include encryption into
my
> product.
> And that's all. So for me is crypting only algorithm with input and
output.
Why do you need a block cipher? What are you trying to accomplish?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Sat, 09 Dec 2000 14:32:09 GMT
In article <j6pY5.382$[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> Well said.....We (the crypto-savvy public) complain when crypto isn't
> available in products (or employs crap algorithms), so surely it's
stupid to
> reply in the manned that Tom has.
>
> People shouldn't have to know everything about what algorithms exist
and so
> on - they should simply be able to ask this simple question in this
group
> and get a civil 'best practice' answer. Crypto is a lot to us but, as
> noname says, it's just a black box with input and output.
>
> Or am I hopelessly optimistic?
No you are very naive. There is more to a secure application then "a
secure block cipher".
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 14:30:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (denis bider) wrote:
> On Sat, 09 Dec 2000 00:06:41 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >> There is a candidate for a universal data format, however, and its
> >> name is XML. But when it comes to digital signature and signature
> >
> >I would argue PGP is rather standard for txt msgs.
>
> Hello Tom - please see the other message I just posted. I think it
> should explain what I meant with a universal data format, and once you
> read that message, I think it should be obvious why text messages are
> irrelevant with those considerations in mind.
>
> Think long term.
PGP has been around for about 10 years now... is that long term enough?
BTW what data is your format for? Normal documents are shared in
either PDF or PS formats which are very portable. I never have used an
XML document nor do I know what one is.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86
Subject: Re: ASM code public/private key cryptography source code
Date: Sat, 09 Dec 2000 14:49:51 GMT
In article <[EMAIL PROTECTED]>,
"James Dorrington" <[EMAIL PROTECTED]> wrote:
>
> Does anyone have (or could direct me to) some source code for public
and
> private key cryptography? Assembly source code prefered (x86.)
>
> thx in advance
Code your own.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 09 Dec 2000 14:35:16 GMT
In article <mPBX5.86$Y2.1524@news>,
"Phil Massimi" <[EMAIL PROTECTED]> wrote:
> Hi. :)
>
> Ok, I'm no expert in cryptography... I'm a simple software developer.
> However, I'm beginning to take an interest in it. I put together my
first
> encryption algorithm for a little custom made chat program of mine,
and
> wondered if anybody would be interested in trying to crack it. There
are no
> keys... simply a formula to encrypt a text string, and another
formula to
> convert it back to text again.
>
> If you get it, I'd be very interested to know what hardware/software
you
> used to crack it, and how long it took you to get through it. Please
send
> any correspondence to [EMAIL PROTECTED] if you don't mind.
>
> Enjoy. :) And thanks! Here's a sample message.
Wow do you ever read the postings in this group? You are the fourth
person this week to post a "crack my algorithm" message. TAKE A HINT.
Read some texts on cryptography before posting algorithms. Or at least
post them properly.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (PB)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 15:15:41 GMT
On Fri, 08 Dec 2000 20:50:06 -0800, Roger Schlafly
<[EMAIL PROTECTED]> wrote:
<snip>
>> The fact is, XML is just as impractical for human inspection as DER. I
>> have had the privilege of working with XML in a real life environment.
>> In such an environment, the majority of XML documents that you meet
>> are computer-generated. These XMLs are usually all stuffed in a single
>> line, no formatting involved, and this is rightly so; such documents
>> are more compact, easier to generate and easier to process. However,
>> they are also very difficult to navigate by hand. What you need to
>> work with these XML documents is... A VIEWER.
>
>Ok, so XML is not perfect. Do you really think the world is going
>to switch to your document format just because it is no worse
>than XML and maybe even slightly better for some narrow particular
>purpose?
um - I've also worked with XML, computer generated, no formatting. But
since the XML is well formed it is possible to apply an XSL stylesheet
to format it up for you - i.e. a VIEWER. Even just loading XML into MS
IE 5 will apply rudimentary formatting - adding paragraphs and
indentions.
If you know the DTD and can write your own XSL then even better.
?? What was the problem with doing this where you worked? Have I been
very stupid?
cheers
pete
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 15:11:27 GMT
On Sat, 09 Dec 2000 15:15:41 GMT, [EMAIL PROTECTED] (PB)
wrote:
>>> The fact is, XML is just as impractical for human inspection as DER. I
>>> have had the privilege of working with XML in a real life environment.
>>> In such an environment, the majority of XML documents that you meet
>>> are computer-generated. These XMLs are usually all stuffed in a single
>>> line, no formatting involved, and this is rightly so; such documents
>>> are more compact, easier to generate and easier to process. However,
>>> they are also very difficult to navigate by hand. What you need to
>>> work with these XML documents is... A VIEWER.
>
>um - I've also worked with XML, computer generated, no formatting. But
>since the XML is well formed it is possible to apply an XSL stylesheet
>to format it up for you - i.e. a VIEWER. Even just loading XML into MS
>IE 5 will apply rudimentary formatting - adding paragraphs and
>indentions.
My point exactly. You need a viewer for XML - and that viewer is IE5.
To view an EDDF, you also need a viewer. But that does not mean that
EDDF is at a disadvantage to XML, because you need a viewer for XML,
too. Support for EDDF can be integrated into IE5 just as easily as
support for XML was.
As a matter of fact, you don't even need Microsoft to do it - you just
have to replace the MS XML parser that comes with Windows with a
parser that supports EDDF, and IE5 will suddenly be able to read EDDF
documents.
Regards,
denis
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
