Cryptography-Digest Digest #298, Volume #13 Sat, 9 Dec 00 13:13:00 EST
Contents:
Re: document signing, XML canonicalization and why EDDF is a better choice (denis
bider)
Re: Custom Encryption Algorithm (Paul Schlyter)
Why PDF and PS won't do it for a Personal Security Device (denis bider)
Re: Revised cipher (Jorgen Hedlund)
Re: Idea for ciphering? (Jorgen Hedlund)
Re: Idea for ciphering? (correction w/ addition) (Jorgen Hedlund)
Re: document signing, XML canonicalization and why EDDF is a better choice (Tom St
Denis)
Re: What's better CAST in PGP or Blowfish 128bit? ("Sam Simpson")
Re: How to embed a key in executable code? (Eric Lee Green)
Re: What's better CAST in PGP or Blowfish 128bit? (Tom St Denis)
Re: Why PDF and PS won't do it for a Personal Security Device (Tom St Denis)
Re: Custom Encryption Algorithm (Simon Johnson)
Re: document signing, XML canonicalization and why EDDF is a better (Mok-Kong Shen)
Re: document signing, XML canonicalization and why EDDF is a better (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 15:18:28 GMT
On Sat, 09 Dec 2000 14:30:59 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>> Think long term.
>PGP has been around for about 10 years now... is that long term enough?
I know that, Tom. I've been around since that time, too. :-)
It seems very much to me that you are mixing apples and elephants
here.
>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.
Perhaps you should take a look. You can get more information about XML
on the following sites:
http://www.w3.org/xml
http://msdn.microsoft.com/xml
http://www.xml.org
http://www.xml.com
You really need to understand the relevance of XML - not only for data
processing in general, but also for widespread use of digital
signatures - before you will be able to appreciate EDDF.
Regards,
denis
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Custom Encryption Algorithm
Date: 9 Dec 2000 15:29:31 +0100
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
> 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.
Oh -- so if there's no key, the encryption becomes uncrackable? <g>
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Why PDF and PS won't do it for a Personal Security Device
Date: Sat, 09 Dec 2000 15:38:30 GMT
On Sat, 09 Dec 2000 14:30:59 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>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
Oh, yes, one more point.
I elaborated in an earlier message that Personal Security Devices will
be essential for ubiquitous use of digital signatures. I also argued
that a generally accepted universal data format will be essential for
ubiquitous use of Personal Security Devices.
What I didn't mention is that this data format will have to be a data
structure format, not a data presentation format.
Formats such as PDF and PS have been designed with presentation, not
security, in mind. When you examine a PDF file, you do not see
information that may be contained in the file, but hidden from
displaying. When you sign such a document, you may inadvertently be
signing something you did not intend to sign.
What we need is a structured data format - one that has been designed
with signatures in mind, and one that you can examine thoroughly with
your PSD before you sign it. EDDF is such a data format. XML is a
structured data format, which is good, but it has not been designed
with security in mind, let alone digital signatures. I think I have
shown in my previous messages that the concept of having a text-based
data format is really off-beat as far as security is concerned, and it
is just as impractical for several other purposes.
Back to PDF and PS formats: not only are they founded on principles
that are incompatible with digital signing, I also do not envision a
PSD capable of displaying a regular sheet of paper in its natural size
for a long time. It is difficult to envision a PSD display to be much
larger than the displays of today's PDA devices. Even if we were to
resolve the issues of inadvertently signing something that a PDF
document contains but did not display, it is still not practical to
examine a PDF or a PS file on a device the size of half a
handkerchief.
Regards,
denis
------------------------------
From: [EMAIL PROTECTED] (Jorgen Hedlund)
Subject: Re: Revised cipher
Date: Sat, 09 Dec 2000 15:44:38 GMT
On Fri, 08 Dec 2000 05:43:27 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>> Use common sense =) Like these examples.
>>
>> around if statements
>>
>> if (abc)
>> {
>> ...
>> }
>> else
>> {
>> ...
>> }
>
>I tend to do:
> if( abc ) {
> ...
> } else {
> ...
> }
>
>The braces are there, but placed differently. It's a matter of
>preference. Both are perfectly valid styles; the important things for
>legibility are that one does place the braces consistently, and that one
>indents consistently. And as to you comment about using common sense,
>what I *meant* when I said "where don't I," was "where haven't I."
Yes I know that it's valid, although it has something to do with my
statement to let some "air" into the code, and if you place the braces
at the end of the line, you "prevent" the "air".. (uhm)..
Well, codestyles differ from person to person, and you're right that
the important thing is to be consistent...
>The braces are there; it's the extra new lines that you're looking for
>and don't see.
Oh, I see the braces... but as explained above... the readability is
lowered when you don't add "air" to the code... that's all...
<snip alot of information, since I've not understood it yet and thus
can't comment it =)>
BR/jh
------------------------------
From: [EMAIL PROTECTED] (Jorgen Hedlund)
Subject: Re: Idea for ciphering?
Date: Sat, 09 Dec 2000 15:49:31 GMT
On Fri, 08 Dec 2000 14:18:56 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>
>Bryan Olson wrote:
>>
>> [EMAIL PROTECTED] wrote:
>> > Mok-Kong Shen wrote:
>> > >
>> > > Sorry, I erred. Since the F's are secret, the STT can be
>> > > public.
>>
>> >
>> > Right =)
>>
>> So what exactly is the public key and how does one ecrypt with it?
>
>The original poster's use of the term 'public key' is
>inappropriate and confusing. He has secret substitutions
>in the scheme and so can leave the STT public. Later he
>apparently saw the advantage of having a secret STT and
>has switched to that in his later posts.
Quite correct, the only problem now is that the key gets awfully big
(256*256*2 bytes (132k))..
I've, since the last posts, tried to optimize the algorithm to allow
smaller keys, or perhaps even keys of dynamic size...
I've not, as of yet, discovered any way and at the same time keep the
"generality" of the STT. I mean, if I for example strip all states
that are not used, then the key-braking would definetly be much
easier.
Also, I've looked a bit at the possiblity to use some logical function
(AND, OR etc.) to minimize the size of the STT, but without success,
as of yet...
I'll post my results when/if I get them...
BR/jh
------------------------------
From: [EMAIL PROTECTED] (Jorgen Hedlund)
Subject: Re: Idea for ciphering? (correction w/ addition)
Date: Sat, 09 Dec 2000 15:57:33 GMT
>Consider, on the other hand, something like 8-bit CFB mode
><snip>
CFB mode?
>Other examples abound. My original point was just that,
>for essentially any stream cipher, you could find a way
>to explain it in terms of the state machine model. You
>just need to figure out what part is the "state", what
>part is the "output function" (i.e., input + state =>
>output), and what is the "state transition" function.
Well, I don't really think that the state is describeable in this
case. Of course, the "current state" depends on the STT together with
the "input stream characters this far"...
I also thought of using the output of the function as input in the
next state.. I wonder though, if it's worth the extra comlexity in
terms of cipherstrength...
I.e. ... Fn(Pn) = Fn-1(Pn-1) + Cn-1
Pn -> Fn(Pn) -> Cn
Where n is current state, Fn is the state function, Pn is the
plaintext character, Cn is the ciphercharacter...
Any comments?
BR/jh
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 15:48:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (denis bider) wrote:
> On Sat, 09 Dec 2000 14:30:59 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >> Think long term.
> >PGP has been around for about 10 years now... is that long term
enough?
>
> I know that, Tom. I've been around since that time, too. :-)
>
> It seems very much to me that you are mixing apples and elephants
> here.
>
> >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.
>
> Perhaps you should take a look. You can get more information about XML
> on the following sites:
>
> http://www.w3.org/xml
> http://msdn.microsoft.com/xml
> http://www.xml.org
> http://www.xml.com
>
> You really need to understand the relevance of XML - not only for data
> processing in general, but also for widespread use of digital
> signatures - before you will be able to appreciate EDDF.
Well it seems like you guys are reinventing the wheel. HTML already
exists for HTTP documents and PDF exists for local documents. Why
invent another method of doing something that already exist?
Anyways.....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Sat, 9 Dec 2000 16:06:10 -0000
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90tfp9$h3m$[EMAIL PROTECTED]...
> 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".
;)
Sure there is, but if the person has to worry about other aspects of
security, why should you make him read journals, books, newsgroups, websites
etc on whether CAST, Blowfish or Idea is best?
Surely cryptography is sufficiently advanced to have "best practices" - or
am I being naive again? ;)
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: How to embed a key in executable code?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Dec 2000 16:17:40 GMT
On Fri, 08 Dec 2000 23:21:58 -0700, Sundial Services <> wrote:
>Give me any software protection scheme and I assure you that it will be
>or has been broken, by one of the many "warez" artists who circulate
Or, rather, will be if it's a piece of software that interests these
people.
>I feel that the most important quality of a software mechanism is ...
>that it exists. The door =is= locked. It does not have to be locked
>with four inches of chromium steel.
>A software protection scheme needs to be simple, sturdy, maintainable,
>and to be something that will not de-stabilize your program. (You have
>plenty enough "real" bugs to deal with.) Above all, it should not
>inconvenience the legitimate purchasers who paid good money for your
>product. And it should not dissuade anyone from choosing to buy...
>which it certainly =can= do.
Absolutely. Some of the things I considered when doing the original
licensing design for BRU 15.1 (that didn't make it into the product
until BRU 16.0, sigh) was:
* license keys must be of a reasonable length. Microsoft might get away with
requiring you to type in a novel in order to use their software, but we
can't. This meant chopping some information that I'd hoped to track in the
license file (sigh).
* Poeple with skill enough to crack our program will crack it, but they
(and most members of pirate groups) aren't potential customers of our
program anyhow. That's one reason that we use a screen door rather
than locking it with four inches of chromium steel. The screen door
will stop casual pirates, while the four inches of chromium steel is
useless anyhow.
* License keys must not use any of the following characters in their
encoding: 1 , l, O, 0, 2, Z. I can't tell you how many license key
cards that I've looked at that were printed on some fuzzy dot matrix
printer where I can't tell what I'm supposed to enter!
* The product must be usable as a demo product without a license key
having been entered. That lets us put it on our FTP site as a demo
product.
There's a lot of other issues that were also involved in the
licensing, that I won't mention here, because that was over a year ago
and I just plain don't remember :-). But the point is that I know,
having done it as part of my job of security engineering, just how
easy it would be to 'strace' and gdb your way through the program and
figure out what is being done. And I also know dozens of ways that I
could make it harder, most of which I encountered during my younger
more callow days when floppy copy protection abounded (I especially
destested the word processor that encrypted itself dozens of times,
and each time it decrypted itself, decrypted the key and a small
subroutine to decrypt itself again) -- but *NO* way to make it
impossible.
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Sat, 09 Dec 2000 17:09:53 GMT
In article <xMsY5.894$[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:90tfp9$h3m$[EMAIL PROTECTED]...
> > 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".
>
> ;)
>
> Sure there is, but if the person has to worry about other aspects of
> security, why should you make him read journals, books, newsgroups,
websites
> etc on whether CAST, Blowfish or Idea is best?
>
> Surely cryptography is sufficiently advanced to have "best
practices" - or
> am I being naive again? ;)
I would trust a "secure application" written by a real cryptographer.
Just because "heart transplants" exist doesn't mean a IT specialist can
perform them right?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Why PDF and PS won't do it for a Personal Security Device
Date: Sat, 09 Dec 2000 17:17:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (denis bider) wrote:
> On Sat, 09 Dec 2000 14:30:59 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >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
>
> Oh, yes, one more point.
>
> I elaborated in an earlier message that Personal Security Devices will
> be essential for ubiquitous use of digital signatures. I also argued
> that a generally accepted universal data format will be essential for
> ubiquitous use of Personal Security Devices.
>
> What I didn't mention is that this data format will have to be a data
> structure format, not a data presentation format.
>
> Formats such as PDF and PS have been designed with presentation, not
> security, in mind. When you examine a PDF file, you do not see
> information that may be contained in the file, but hidden from
> displaying. When you sign such a document, you may inadvertently be
> signing something you did not intend to sign.
Well given any file format (except raw data) you sign data you didn't
see. such as file headers, id tags, etc...
If I read a PDF file and verify that it is mine, then I sign the file
(treating it as a raw binary) then as long as the signature is verified
on the other end I can be assured they are reading the same pdf file.
Therefore reading what I wanted them to, QED. This assumes that the
public/private keys have been negotiated and are distributed properly.
Obviously trivial attacks exist on any system where he keys are
compromised...
> What we need is a structured data format - one that has been designed
> with signatures in mind, and one that you can examine thoroughly with
> your PSD before you sign it. EDDF is such a data format. XML is a
> structured data format, which is good, but it has not been designed
> with security in mind, let alone digital signatures. I think I have
> shown in my previous messages that the concept of having a text-based
> data format is really off-beat as far as security is concerned, and it
> is just as impractical for several other purposes.
I would disagree. If I want to sign a contract or a digital cheque I
care very little for "pretty little graphics" and "upbeat tables". I
want text saying my vitals and the vitals about the transactions.
I doubt many people will write books then digitally sign them.
> Back to PDF and PS formats: not only are they founded on principles
> that are incompatible with digital signing, I also do not envision a
> PSD capable of displaying a regular sheet of paper in its natural size
> for a long time. It is difficult to envision a PSD display to be much
> larger than the displays of today's PDA devices. Even if we were to
> resolve the issues of inadvertently signing something that a PDF
> document contains but did not display, it is still not practical to
> examine a PDF or a PS file on a device the size of half a
> handkerchief.
True PS files can get quite large, but on PDAs today there is
sufficient processing power to decode a PDF file given sufficient
memory to hold them. A 10 page document without graphics may be upto
about 100kb at the most in a PDF (most likely less) and many PDAs could
view them.
Even better is to use a plain text file :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 09 Dec 2000 17:27:14 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.
>
> 0010201313000711400110710511001009221021911110020
> 00171107061101111113113019010401111923230310110020
> 18111130314712111601412711130171111121121007011011
> 17700101012202012011001091300110353201040101019130
> 11302303119084111111302021140461103022301620101111
> 11010051200411170901813441913191011711121310110301
> 17713011112010195000210121714400311001000910000310
> 18101111110060121313135011001290211710143820370461
> 71300100110321101011310530011024112401110371011121
> 05110121111001110121421019073131101010109103211110
> 11803611710314171106211111111151371613201010202036
> 13131111119707017126653103312002901039607201191110
> 51011196153110714052450098260170948924102310710014
> 72129012920101173119091091503341619210431012171502
> 410332399301319421369610305224206391921273200891
>
>
Even though you have not given me an algorithm to work with, i can
point out some flaws in this cipher just by looking at the cipher-text.
e.g. You have a row of 9 ones in succession. If this were a good
cipher, then you would have an even distribution of digits. However,
the probability of a string of nine '1's occuring in a row is 1/10^9 or
one in a billion.
Based on this, I conclude your algorithm isn't very secure.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Date: Sat, 09 Dec 2000 18:49:37 +0100
denis bider wrote:
>
[snip]
> 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.
[snip]
> - And thirty years from now everyone uses EDDF.
Just for my understanding: You mean that EDDF can
completely replace XML, because it provides the same
functionalities and is more rigorous and is just as
well (or even better) user-friendly. Is that right?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Date: Sat, 09 Dec 2000 18:50:59 +0100
Tom St Denis wrote:
>
> I never have used an XML document nor do I know what one is.
I thought you do have a web page. XML is the successor
to HTML (a revised version so to say).
M. K. Shen
------------------------------
** 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
******************************
