Cryptography-Digest Digest #889, Volume #10 Wed, 12 Jan 00 13:13:01 EST
Contents:
Re: My background - Markku Juhani Saarelainen (Markku-Juhani O. Saarinen)
Why is EDI dead? Is S/MIME 'safe'? Who and why? (James Redfern)
Re: Demcom's Steganos Security Suite (James Redfern)
Re: AES & satellite example (Nicol So)
Re: My background - Markku Juhani Saarelainen ("cryptosporidium")
lfsr - polynom ([EMAIL PROTECTED])
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? ("Richard A. Schulman")
Re: About DES algorithm. (John Savard)
Re: Simple Encryption ... (Anton Stiglic)
Re: "1:1 adaptive huffman compression" doesn't work (Tim Tyler)
Re: Simple Encryption ... ("Derek Potter")
Re: Questions about message digest functions (Tim Tyler)
LSFR ("Michael Darling")
Re: Questions about message digest functions (David Wagner)
----------------------------------------------------------------------------
From: Markku-Juhani O. Saarinen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Re: My background - Markku Juhani Saarelainen
Date: 12 Jan 2000 10:45:53 GMT
In sci.crypt Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
> 1. Born in 1967 in Varkaus, Finland
> 2. Educated in Finland, U.S.A. and the USSR
> 3. Political beliefs: no political beliefs
> 4. Major Achievements:
(..)
I would like to make a public statement: I do not have ANYTHING to do
with Mr. Markku J. Saarelainen (despite similar names).
PLEASE do not confuse me with this wannabe-spy (whatever) person.
- mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Wed, 12 Jan 2000 11:15:51 +0000
Reply-To: redfern<AT>privacyx<DOT>com
If anyone can help me with this one I would much appreciate it.
I have a friend who is in the remote document processing business - invoices,
price-lists, technical drawings etc. His software is NT based and normally
works over a LAN/WAN configuration. He made the statement to me recently that
"EDI is dead" and that he will start a new project to produce remote documents
using 'intelligent' interception and formatting of data streams from legacy
type hardware, BUT, via the Internet.
My questions are: why is EDI 'dead' and what did it die from? What are the
security implications and will S/MIME be enough 'en-route' protection? And,
anyway, who would need to run a main-frame somewhere and output their data to
PCs or printers somewhere else in the world?
If you think you know the answers... you're already smarter than me.
JR.
--
James Redfern <[EMAIL PROTECTED]> The Redfern Organization
PGP key ID 0x8244C43A from <mailto:[EMAIL PROTECTED]?subject=0x8244C43A>
...ActiveNames delivers my undeliverable mail at <www.ActiveNames.com>
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Demcom's Steganos Security Suite
Date: Wed, 12 Jan 2000 11:16:07 +0000
Reply-To: redfern<AT>privacyx<DOT>com
On Sat, 08 Jan 2000 16:55:55 +0000, James Redfern <[EMAIL PROTECTED]>
wrote:
| Does anyone have any experience of Demcom's Steganos II Security Suite or
| anything useful to say about their methods or algorithms used?
|
www.steganography.com/english/steganos
If you want to try it out.
JR.
--
James Redfern <[EMAIL PROTECTED]> The Redfern Organization
PGP key ID 0x8244C43A from <mailto:[EMAIL PROTECTED]?subject=0x8244C43A>
...ActiveNames delivers my undeliverable mail at <www.ActiveNames.com>
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Wed, 12 Jan 2000 07:40:08 -0500
Reply-To: see.signature
David Wagner wrote:
>
> In article <[EMAIL PROTECTED]>,
> Doug Stell <[EMAIL PROTECTED]> wrote:
> > For example, I know of systems where classified algorithm code in
> > encrypted under an algorithm specific to that function and the
> > encrypted code image is signed under another algorithm specific to
> > that purpose. Both of these algorithms that protect the code from
> > substitution and disclosure are dedicated to these functions, not used
> > for anything else and can not be replaced.
>
> By the way, this sounds like a lovely application for an
> informationally-theoretic (provably-secure) cryptosystem,
> e.g., the one-time pad and the information theoretically
> secure message authentication schemes.
Exactly.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "cryptosporidium" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Re: My background - Markku Juhani Saarelainen
Date: Wed, 12 Jan 2000 12:43:11 -0000
"Markku J. Saarelainen" <[EMAIL PROTECTED]>
> 4. Major Achievements: A feeble troll in sci.crypt.
Bloomin' weejuns! ;)
------------------------------
From: [EMAIL PROTECTED]
Subject: lfsr - polynom
Date: Wed, 12 Jan 2000 15:11:57 GMT
My problem is, to choose feedback polynoms
for a stream cipher system consisting of
lfsr.
In which way i find a suitable polynom?
Rueppel write in his book (analysis and design
of stream ciphers) to choose a polynom which
produce random sequences which lin. complexity
is near to his period length. Is this rigth?
In other books the use of primitive polynoms
is recommended. Primitive Polynoms produces
m-sequences which period length ist very differnt
from the lin. complexity of such a sequence.
Can anyone help me?
thank you for reading
gransche
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Richard A. Schulman" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Wed, 12 Jan 2000 10:38:55 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"James Redfern" <[EMAIL PROTECTED]> wrote:
>... My questions are: why is EDI 'dead' and what did it die from?
I'm not sure what your friend means, unless he is referring to
traditional EDI. With the advent of XML, it is anticipated that there
will be a major increase in EDI applications because of the fact that
XML, as a standard language for representing content, makes it much
easier to overcome differences between the proprietary data formats
used by different companies.
> What are the
> security implications and will S/MIME be enough 'en-route'
> protection?
I can't comment on S/MIME, but XML can be encrypted using existing
technologies.
>And,
> anyway, who would need to run a main-frame somewhere and output
> their data to PCs or printers somewhere else in the world?
EDI exists for the reliable interchange of formatted data between
computers. Whether the source is a mainframe, desktop, or laptop, and
whether the target is computer or printer "makes no never mind" (as
one of my aunts if fond of saying).
- --
Richard Schulman
(for email reply, remove the anti-spamming 'XYZ')
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBOHyf9XOwGWOvuFK/EQIXWgCgj9kJhBRy9jrSLVKSGYwOA4hhHTQAoJe9
HD3hoGXyj3J4H1r+2FuMz0X/
=UKL5
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: About DES algorithm.
Date: Wed, 12 Jan 2000 08:57:29 GMT
Katsamakas Kostas <[EMAIL PROTECTED]> wrote, in part:
>��� I know that unix systems use the crypt function to encrypt a
>password.
>According to the man page, this function uses a variation of the DES
>algorithm
>using two extra characters as salt.
>Where can i find the description of the algorithm the crypt function
>uses, so i could implement it?
I think that's fairly easily available, but it's a hash algorithm, not
an encryption algorithm.
>I would like also the DES algorithm.I have searched, but i have found
>general descriptions of it.
There's a full description on my web site, and the original standard
is also available at http://www.nist.gov/.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Wed, 12 Jan 2000 11:13:11 -0500
==============82F10D90024CAB7BEBA5453B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
David Wagner wrote:
>
> I'll repeat that, if I understood correctly,
> the primitive the poster was asking for is
> known as `bit commitment'. Zero-knowledge
> proofs are a fine way to build a bit commitment
> scheme, but they're hardly the only way.
You've got it the other way around,
bit commitment scheme => Zero-Knowledge proofs
and *NOT*
ZK proofs => bit commitment scheme
You can construct a ZK proof from a bit commitment scheme.
In fact, with a bit commitment scheme, you can construct
a multi-party computation protocol, which enables you
to proove (with ZK) that you have a solution to an NP-complete
problem (for *any* NP-complete problem).
(This is a big problem with multi-party computations and ZK proofs
in a quantum world, since you can't have a bit commitment in a
quantum world).
There are other ways to build ZK proofs do. You can use Verifiable
Secret Sharing schemes to construct multi-party protocols, or even
a deck of cards:
http://www.iro.umontreal.ca/~stiglic/Crypto/cartes.ps
For a good intro see Stinson's book, or for more advanced stuff
Claude Crepeau has a bunch of articles:
http://www.cs.McGill.ca/~crepeau/pub_en.html
Now, for what the initial poster wanted, I agree that ZK proofs
might be a little bit overkill, the request seems to have some
vagueness to me.
Anton
==============82F10D90024CAB7BEBA5453B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David Wagner wrote:
<blockquote TYPE=CITE>
<br>I'll repeat that, if I understood correctly,
<br>the primitive the poster was asking for is
<br>known as `bit commitment'. Zero-knowledge
<br>proofs are a fine way to build a bit commitment
<br>scheme, but they're hardly the only way.</blockquote>
You've got it the other way around,
<br> bit commitment scheme => Zero-Knowledge proofs
<p>and *NOT*
<br> ZK proofs => bit commitment scheme
<p>You can construct a ZK proof from a bit commitment scheme.
<br>In fact, with a bit commitment scheme, you can construct
<br>a multi-party computation protocol, which enables you
<br>to proove (with ZK) that you have a solution to an NP-complete
<br>problem (for *any* NP-complete problem).
<br>(This is a big problem with multi-party computations and ZK proofs
<br> in a quantum world, since you can't have a bit commitment in
a
<br> quantum world).
<br>There are other ways to build ZK proofs do. You can use Verifiable
<br>Secret Sharing schemes to construct multi-party protocols, or even
<br>a deck of cards:
<br><a
href="http://www.iro.umontreal.ca/~stiglic/Crypto/cartes.ps">http://www.iro.umontreal.ca/~stiglic/Crypto/cartes.ps</a>
<p>For a good intro see Stinson's book, or for more advanced stuff
<br>Claude Crepeau has a bunch of articles:
<br><a
href="http://www.cs.McGill.ca/~crepeau/pub_en.html">http://www.cs.McGill.ca/~crepeau/pub_en.html</a><a
href="http://www.cs.McGill.ca/~crepeau/pub_en.html"></a>
<p>Now, for what the initial poster wanted, I agree that ZK proofs
<br>might be a little bit overkill, the request seems to have some
<br>vagueness to me.
<br>
<p>Anton
<pre></pre>
</html>
==============82F10D90024CAB7BEBA5453B==
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jan 2000 16:39:14 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler schrieb:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : I am not quite sure whether one couldn't even attempt to 'define'
:> : the 1-1 problem away with a 'convention'. That is, if on compression
:> : the last code symbol does not fill to a byte boundary, then the
:> : software has to do filling with bits that do not form a valid code
:> : symbol and it is 'required' by convention that the filling is
:> : to be random, say dependent on the system clock. [...]
:>
:> This is pretty much the same technique as John Savard proposed.
:>
:> It works to the extent that you can generate genuinely random bits.
:> If your bits are not completely random then you still have problems.
:>
:> You also wind up with a non-deterministic compressor. The system
:> fails to exploit the range of the compressor to itsgreatest possible
:> extent. It is no longer portable to embedded environments with no
:> obvious reliable source of genuinely random noise available.
: No.
Yes.
: Whether the software on two runs of compression put in the
: same bunch of (supposedly) random bits is of no significance.
It makes little difference to security - if the padding is genuinely
random. But it may not be of *no* significance overall. For example it
prevents the end user from checking whether two files deccompress to
identical results by using the "diff" program on the compressed files.
Very few things are of no significance at all.
As a sample security concern, compressing the file and encrypting it
will no longer produce the same result.
This means if the file gets lost and you have not stored a local copy you
may wany to recompress and reencrypt, using the original key. Normally
this will involve few security problems, as eavsdroppers gain little
additional information from the identical cyphertext. However a "random"
compressor ending gives them two files, encrypted with the same key, with
a few bits of plaintext differing between them.
This may give the attacker information about - for example - the block
size being used, which he did not have from the original message alone.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Standing on head makes smile of frown, but rest of face is upside down.
------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Wed, 12 Jan 2000 17:31:17 -0000
"Anton Stiglic" <[EMAIL PROTECTED]> wrote
> Now, for what the initial poster wanted, I agree that ZK
proofs
> might be a little bit overkill, the request seems to have
some
> vagueness to me.
some? :)
One of the points was that the scheme
had to be obvious to the layman. Handing
the onlookers a black box hasher or whatever
to verify your claim could be a big minus.
Anyway, I'm glad you were kind enough to take
the question seriously and point me to some
introductory texts on serious encrytion.
Thanks again.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jan 2000 17:26:34 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:> However, a near flat distribution is always the ideal, [...]
: Why? It is widely accepted by most theoretical cryptographers that
: a random function is the ideal, for many purposes. That doesn't mean
: they are necessarily right -- noone is infallible -- but they've put
: forward some pretty compelling arguments to support this contention.
: This means that, if you want to say the conventional approach is wrong,
: you ought to have some pretty good evidence for why your favorite
: definition is to be preferred over the conventional approach. So far,
: I haven't seen you make any such reasoned arguments.
I'm sorry - I thought I had done so in my eariler posts.
To restate my position, a pseudo-random function is less-than ideal
when the size of the messages being hashed typically approaches the size
of the hash.
In fact a pseudo-random function is less than ideal under all
circumstances, but the problem only reaches a significant magnitude
when the hash size is close to the typical message size.
To illustrate the problem, it is perhaps simplest to consider the
case where the size of the message and the size of the hash are equal.
In this case, it is possible to construct a hash which is a bijection
between the space of all messages of that length and the space of possible
hashes. This eliminates the possibility of hash collisions for such
messages.
When using a pseudo-random function hash collisions may be found.
This makes a brute-force search a possibility, and finding hash
collisions is consequently easier than it needs to be whenever
messages are constrained to be of a certain size.
A simple one-way, variable length hash has been presented, based on RSA.
This appears to be slower and less secure than conventional hashes - but
at least illustrates that such constructions are possible.
Another use of one-way hashes is to distill entropy from a given stream
of data.
A conventional PRF actually dilutes the entropy in some streams of data,
*despite* being offered more message than hash.
Given a source of randomness the size of the hash, almost an entire
bit on entropy is typically totally lost from a high entropy file by
applying a PRF-style hash to it. Much the same - though to a reduced
degree - happens with slightly longer messages. To have a hash dilute
entropy from a longer message, rather than condense it seems very
undesirable. Clearly this does not happen with a hash with the ideal
distribution I'm discussing.
These failures of conventional hashes to operate according to standard
descriptions of the properties it is desirable for hashes to have when
used at small scales is caused by the fact that the distribution of
frequencies of the hash values is the bell-shaped curve produced by
randomness, rather than the maximally flat distribution in the face of
target messages that seems desirable.
This discussion assumes that message length is constrained in some way.
In addition to avoiding hash collisions between messages of the same
size, it further seems desirable that the distribution of hashes is flat
when message length is limited to be below a specified size. These are
both born of worldly considerations, concerned with how hashes are used
in practice.
*If* there were no circumstances where there was any a-priori information
about message size, and no reason for an attacker to want to forge a
message with the same length as an existing message, then a PRF would do
fine as a hash. However message size *is* rarely completely unknown.
*Often* there are constraints placed on the size of the message.
Sometimes all messages are the same size. Sometimes, message size is
known to the recipient in advance - e.g. when a message is retransmitted
after being garbled in transit, so any forgery needs to take this into
account.
In practice, smaller messages are more common than large ones. This
alone affects the distribution of hashes that is desirable.
It should be obvious that hashes with a better distribution than that
profided by a PRF can be created when the one-way property is not
required.
However there still appears to be a question mark hanging over whether
*one-way* hashes with better distributions can be constructed with the
speed, or security that today's conventional hashes have.
This makes no difference to which distribution is most desirable, but
affects whether it can be attained in practice.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Taxes are not levied for the benefit of the taxed.
------------------------------
From: "Michael Darling" <[EMAIL PROTECTED]>
Subject: LSFR
Date: Wed, 12 Jan 2000 17:34:38 -0000
We wish to use an LSFR to generate a time stamp for an electronic component
we are designing.
The idea is to use a very simple 2 tap LSFR which is 49 bits long with taps
at bit 9 and bit 0.
This would provide us a nice non-repeating sequence which we could use to
uniquely identify each stamp.
Now then: We want to say when each stamp occurred, i.e. map each output to
its location in the sequence.
In other words we want to get an output and say that it is output 'n' in the
sequence.
Obviously, we don't want to run through the sequence in software and match
the output we got from the
hardware - as this could take some time :)
Are we being naive to expect that we can do this, or is there a method that
we don't know about?
Thanks in advance for any replies,
Mike Darling.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Questions about message digest functions
Date: 12 Jan 2000 09:44:48 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> When using a pseudo-random function hash collisions may be found.
> This makes a brute-force search a possibility, and finding hash
> collisions is consequently easier than it needs to be whenever
> messages are constrained to be of a certain size.
This doesn't make any sense to me.
So long as you choose the output length to be large enough (e.g., 160 bits),
brute-force collision search is infeasible. So who cares if collisions exist,
if they can't be found?
I assume we're talking about computational security, where the computational
resources of the adversary are assumed to be bounded, right?
> A conventional PRF actually dilutes the entropy in some streams of data,
> *despite* being offered more message than hash.
But the dilution is very small, and only becomes non-negligible when the
entropy in the input closely approaches (or exceeds) the output size.
Even then, you only lose at most about 1 bit of entropy or so. Typically,
you don't need 160 bits of entropy; 128 is more than enough. So, who cares
if you only get 159 bits of entropy out, rather than 160?
Note also that the entropy loss is very small if the input entropy is
considerably less than 160 bits. So in the cases where entropy is scarce,
dilution is negligible.
Are those the worst disadvantages of non-bijective hash functions?
If so, I'm happy to live with them -- they are insignificant, IMHO.
------------------------------
** 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
******************************
