Cryptography-Digest Digest #299, Volume #13 Sat, 9 Dec 00 16:13:01 EST
Contents:
Re: Custom Encryption Algorithm (Tom St Denis)
Re: document signing, XML canonicalization and why EDDF is a better (Roger
Schlafly)
Re: document signing, XML canonicalization and why EDDF is a better (Roger
Schlafly)
Re: Custom Encryption Algorithm (Simon Johnson)
Re: document signing, XML canonicalization and why EDDF is a better choice (denis
bider)
Re: [globera announcement 2] Professional support for Crypto++ available (David
Hopwood)
Re: document signing, XML canonicalization and why EDDF is a better choice (denis
bider)
Re: voting through pgp (Johnny Bravo)
Re: voting through pgp (Johnny Bravo)
Re: Why PDF and PS won't do it for a Personal Security Device (denis bider)
Re: voting through pgp (Johnny Bravo)
Re: Custom Encryption Algorithm (David Schwartz)
EDDF: the intended audience (denis bider)
Re: How to embed a key in executable code? ("Matt Timmermans")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 09 Dec 2000 18:03:06 GMT
In article <90tq1e$oer$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> 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.
Your observation is correct however your conclusion is not. A valid
RNG may output a zillion zero bits and still be random. You observed a
bias in his cipher, perhaps due to the fact it's probably some sort of
simple monoalphabetic substitution mixed with a Vinegere cipher. Who
knows. Just because there are alot of 1's doesn't make it weak.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Date: Sat, 09 Dec 2000 10:16:39 -0800
denis bider wrote:
> 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.
Have you done that? What percentage of PC users do you think are
going to rewrite the MS DLLs just so their signatures will conform
to your format?
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: document signing, XML canonicalization and why EDDF is a better
Date: Sat, 09 Dec 2000 10:21:35 -0800
denis bider wrote:
> 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.
> ...
> 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.
This makes no sense to me. First you say it is difficult to
convert an XML document to canonical form, and then you say
that it is simple.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 09 Dec 2000 19:46:08 GMT
In article <90ts4o$ptd$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <90tq1e$oer$[EMAIL PROTECTED]>,
> Simon Johnson <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Your observation is correct however your conclusion is not. A valid
> RNG may output a zillion zero bits and still be random. You observed
a
> bias in his cipher, perhaps due to the fact it's probably some sort of
> simple monoalphabetic substitution mixed with a Vinegere cipher. Who
> knows. Just because there are alot of 1's doesn't make it weak.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Yes, i agree with this. It is quite feasible that the text given above
could have been a random source. But since he said the sample was
produced by an algorithm that encrypted non-random plain-text, the lack
of randomness would indicate a poor cipher.
This said, secure ciphers can be designed with compressable cipher-
text. The compressability of a document is dependent on the amount of
entropy the document contains and thus its randomness. Generally, the
more random the less compressable. So although the randomness of the
sample can be a good indicator of security, it is nothing hard and fast
and can be quite wrong in somecases.
Simon.
--
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: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 20:09:17 GMT
On Sat, 09 Dec 2000 18:49:37 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>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?
Yes, that would be correct - except that "developer-friendly",
"system-designed-friendly", and "security-friendly" would probably be
more proper terms.
Regards,
denis
------------------------------
Date: Sat, 09 Dec 2000 20:08:12 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: [globera announcement 2] Professional support for Crypto++ available
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (denis bider) wrote:
>
> > globera, a Ljubljana, Slovenia-based consultancy and integration
> > company specializing in digital security, announces open availability
> > of professional support for the public domain Crypto++ library.
>
> Unless your services are free you just SPAMMED this group.
IMHO the announcement was perfectly reasonable, on-topic, and not spam.
Although I have no evidence, positive or negative, about the competence
of this particular company, in general professional support for open-source
crypto libraries is something to be encouraged, and is likely to be of
interest to a fair proportion of the readers of this group. At least
they've chosen a well-designed library to support.
Even if the article had been spam, quoting it in full and adding a single
line saying that it is spam in your opinion, is simply annoying, and not
at all helpful.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOjHN9DkCAxeYt5gVAQFpqggAnMsaXIxI6uAtvyS+d30uU7BDkZqHVD2m
saE77gLa+RwpvYsmsjt4K3zO7sdIcidkqfto1q2QokMtg23KAxm5w9KJZfWi9MWU
T4VX3xxi7VuCHUXlNxbFa3VK9etoEuqPo7R4zthw9/Oyl2i2KqO+ydqMSoAjcGuS
Ie6bRLz4nM9gX8gnbn4qkSURGhvn0UvVBy9RQ0B5r5w/FPrpxX17FBnLDwYnfJ8Q
u4U9t3A36eiwNySANDrHQmxozMfgWMj2kS8R97I6H/DzY+p5ctBZP66vO+8pdUHv
0TbQbzuFJEtwhJq/Pn2d6HPq12CyklMAeeQZiqW9LALaZnRMJPa5mg==
=KHQK
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: document signing, XML canonicalization and why EDDF is a better choice
Date: Sat, 09 Dec 2000 20:34:49 GMT
On Sat, 09 Dec 2000 10:21:35 -0800, Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>> 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.
>> ...
>> 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.
>
>This makes no sense to me. First you say it is difficult to
>convert an XML document to canonical form, and then you say
>that it is simple.
Thank you for pointing this out. It seems I wanted to say two things
at once, and it came out rather confusing. To explain:
(1) If you have a system that generates regular (non-canonical) XML
documents; and if you need documents in their canonical form, which
you probably will; you will have to convert documents from
non-canonical form to canonical form all the time. This is a lot of
unnecessary extra effort that involves a complex set of rules, is
error-prone and opens potential vulnerabilities.
(2) On the other hand, it is a relatively simple task to switch from
XML to EDDF. It is a one-time effort, consisting primarily of
replacing your XML parser with the EDDF parser, and converting
existing XML documents to EDDF. This conversion does involve a
relatively complex set of rules; but it only has to be done once.
Compared to other one-time undertakings, this is one of the simpler
ones.
The benefit of changing to a system that only generates canonical
documents is that, once you need a document in its canonical form, you
won't have to convert it. The basic premise is that, in time, you will
need documents in their canonical form more and more.
Of course, just as easily as you can convert from an XML system to an
EDDF system, you can also convert from a regular-XML-system to a
canonical-XML-system. However, you have to update your parsers in both
cases. Converting from regular-XML to canonical-XML is at least as
difficult as converting from XML to EDDF. Actually, my argument is
that the latter is actually simpler, and less error-prone. And since
EDDF is, if you trust my words, technically sounder - why not just
convert to EDDF?
Regards,
denis
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: Sat, 09 Dec 2000 15:42:16 -0800
On Fri, 10 Nov 2000 18:35:10 GMT, "binary digit"
<[EMAIL PROTECTED]> wrote:
>Imagine if everyone had pgp in the world and voted through pgp, every single
>vote could be verrified and everyone would be happy, and there wouldnt be
>this problem that is going on now in florida
Slight problems; for one you are going to be short hundred million
computers, tens of thousands of power plants, a few billion miles of
electical cable, several million phone jacks, a few billion miles of
phone lines, a few hundred thousand teachers, years of time, hundreds
of thousands of programmer manhours and thousands of trillions of
dollars, and a constitutional ammendment to allow non citizens to vote
for the election of the American president.
Other than that it's a great plan, write the check and I'll start it
at once.
--
� Best Wishes,
� � Johnny Bravo
BAAWA Knight, EAC - Temporal Adjustments Division
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all its contents." - HP Lovecraft
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: Sat, 09 Dec 2000 15:43:17 -0800
On Fri, 10 Nov 2000 23:29:24 GMT, [EMAIL PROTECTED] wrote:
>It's an ease of coercion problem, right now to directly influence the
>vote of a person, I need to without being noticed enter the voting
>booth with that person, or verify their ballot before it enters the
>box. Two very visible things, both to the people waiting to vote, and
>to the people observing the process to gaurentee that these things
>don't happen.
Not really. Lets say I threaten to kill you if Gore wins the county
you are voting in and my threat is credible, you know I'm willing and
able to do it. Do you really think that you are going to take any
chances when you are in the voting booth, even knowing you are in
private.
The trouble is that races are seldom close enough to make this work.
As it is in Florida you would have had to convince more than 70 people
that you could and would really kill them if the vote didn't go the
way you wanted. But that is with perfect hindsight, what if you
really needed 50,000 votes, how are you going to manage that on a
personal level? Threaten to set a nuke off in Orlando if you don't
like the election results?
>For the sake of security, we need a centralized location where votes
>are made, where a small number of people are trusted. Home voting is
>far from this, and should be restricted to those individuals who
>require the home vote ability in order to effectively vote (i.e. those
>people who are physically unable to leave their residence).
Doesn't seem to be a problem in Oregon, where the majority of all
voters take the option to mail in a ballot.
--
� Best Wishes,
� � Johnny Bravo
BAAWA Knight, EAC - Temporal Adjustments Division
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all its contents." - HP Lovecraft
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: Why PDF and PS won't do it for a Personal Security Device
Date: Sat, 09 Dec 2000 20:48:17 GMT
On Sat, 09 Dec 2000 17:17:29 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>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.
Anything is feasible. After all, we did put a man on the Moon.
But feasibility is not the point. Of course it is possible to sign a
PDF document on a PDA. My argument is not that it is impossible, my
argument is that it is error-prone and impractical. My argument is
that there are formats that are better suited for digital signature
than PDF, or plain text, or PS files.
If you want to insist that it is still possible to use PDF - yes, it
is possible. But the actual point is that other formats exist that are
better suited for this purpose. It is not my intention to bash these
data formats; the opposite, they are good at what they do, and I
personally use these formats in practice.
What I want to show is that EDDF has technical merits that make it
better suited for most purposes than XML, and that similar technical
merits make it more suitable for *some* purposes than, say, PDF or
plain text. This point, I think, I have already shown.
Regards,
denis
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: Sat, 09 Dec 2000 15:49:35 -0800
On 11 Nov 2000 03:31:06 GMT, [EMAIL PROTECTED] (David Wagner)
wrote:
>SCOTT19U.ZIP_GUY wrote:
>> Ahh but what about ghost voters. You give a buch of bums
>>cigarattes and have them vote your way.
>
>Yes, I think we should take care to think very carefully about
>these attacks before changing the system!
Not really an attack, it's an even chance for both parties to buy
votes. It's your vote, you have a right to sell it as dearly or
cheaply as possible.
There were several coordinated groups in Florida taking people to
the polls, however they were only transporting democrats. Is that an
"attack", or simply the right of any citizen to encourage his fellow
democrats to vote?
--
� Best Wishes,
� � Johnny Bravo
BAAWA Knight, EAC - Temporal Adjustments Division
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all its contents." - HP Lovecraft
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 09 Dec 2000 12:41:12 -0800
Paul Schlyter wrote:
>
> 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>
No, it becomes useless. You have to trust everyone who has ever used
the algorithm in order to trust the algorithm.
You'll notice in this case that the poster has so little confidence in
his algorithm that he has provided no information whatsoever. For
example, no plaintext/ciphertext pairs are offered. No information about
its architecture is offered.
He might as well have said, "I have thought of a great algorithm and
challenge anyone to break it. If you break it email me."
DS
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: EDDF: the intended audience
Date: Sat, 09 Dec 2000 21:03:51 GMT
On Sat, 09 Dec 2000 10:16:39 -0800, Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>> 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.
>
>Have you done that? What percentage of PC users do you think are
>going to rewrite the MS DLLs just so their signatures will conform
>to your format?
It is not my purpose to force EDDF into end users' mouths. End users
will use what is available, and if XML is available, that is what they
will use. If XML is the only thing there is, I support its use; it is
a strong and flexible data format. It is based on the wrong
foundations, but it is nevertheless a good idea.
My intention with EDDF is to reach people who are actually involved
with designing products and systems. These people are the ones who
will be able to see the merits of one data format with regard to
another, and they are in a position to decide what format will
actually be used in practice.
In five years, we will either be standardised on canonical XML with
its inherent disadvantage of being text-based, or something like EDDF
will take over. I think there is a fair probability that canonical XML
is what will actually happen. However, I am convinced that XML is not
by far the optimal choice; so, what I am doing is trying to let people
know that there is an alternative.
The alternative is called EDDF, there is a free ANSI C parser, there
is a nice C++ front-end, and it has potential to be everything that
XML is, and much of what it is not. So there.
Regards,
denis
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Sat, 09 Dec 2000 21:01:33 GMT
"Eric Lee Green" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Not really. If you have a legal license, you just single step through the
> program until you find where it reads the license data off the disk. Then
> the programmer may have employed some obfuscation at this point -- e.g.,
> perhaps performs some algorithmic manipulations upon the data -- but
> usually you can single step past that to where he has set all his data
> variables such as, e.g., "number of users", and simply hard-wire that.
"usually" is the operative word. I'm not talking about what happens
"usually", i.e., when copy protection is written by people who don't know
how to do it "properly". As far as I know, "people who don't know how to do
it properly" includes me and everybody else right now.
My point is that we have nothing but faith and experience to suggest that
reverse engineering is feasible. Faith and experience is enough to say that
reverse engineering is _usually_ feasible, but if you want to say that
reverse engineering is _always_ feasible, you need proof.
We have no P-time algorithms for reverse engineering, and no reason to think
we could invent them. Joe thinks that humans can do things that algorithms
can't, but there is no proof of that either -- it's a matter of faith.
Certainly, a well-defined reverse engineering problem can always be reduced
to a stopping problem, but that's undecidable. Many well-defined reverse
engineering problems can probably (like the DES encryptor) be reduced to an
NP-complete problem, but people aren't demonstrably effective in solving
those, either.
The DES encryptor is a concrete example. Given a DES encryptor, is there a
tractable algorithm for extracting the built-in key? If you cannot provide
such an algorithm, cannot point to a reference that does, and cannot find a
proof of the problem's feasibility, then you have only faith and experience
to suggest that it can be done in a reasonable amount of time.
If we didn't have public-key cryptography already, I'm pretty sure that
faith and experience would have suggest that it was impossible -- the
program performs an invertable operation using only publicly available data,
but noone can invert it?!?!
------------------------------
** 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
******************************
