Cryptography-Digest Digest #102, Volume #13 Sun, 5 Nov 00 10:13:01 EST
Contents:
Re: Crypto Export Restrictions (CiPHER)
Re: DATA PADDING FOR ENCRYPTION (Tim Tyler)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: RSA vs. Rabin (Francois Grieu)
----------------------------------------------------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Sun, 05 Nov 2000 13:05:50 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Anyone who uses encryption software that does not generate pure
> random numbers is nutty if you ask me.
No computer program can generate pure random numbers, no computer
program requesting input from users will generate pure random numbers,
in fact I'd go as far as saying that 90% of the time in all occasions
in life 'pure' randomness cannot be attained. Perhaps that's getting
into too much arithmetic theory for you though - you can't even
understand the concept of equations.
/* He also doesn't seem to grasp the concepts of simple open
cryptography, his guide/help file is vague (at best) and generally
posting messages such as - "Nothing in this world comes easy. These
guys wanted to be spoon fed. I hope they are wise enough to know that
they get what they pay for. n this case, they got what they made the
personal effort to achieve." - makes him come across as a bit of a
twat.
That's not to mention the fact that he took so much pride in showing
everyone how little he kept himself up to date on US export
restrictions. Which was quite funny. */
I'd advise everyone to treat this guy's/company's (lol) programs like
the plague and use something infinitely better like PGP or even
something like a nice implementation of DES, Blowfish, Twofish, etc.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Nov 2000 13:59:29 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Bryan Olson wrote:
:> : Tim Tyler wrote:
:> :> Bryan Olson wrote:
:> :> : One who cannot trust computational security might reasonably
:> :> : use the OTP.
:> :>
:> :> If they can handle the large keys involved.
:> :>
:> :> : But presenting this as a justification for bijective padding is
:> :> : nonsense.
:> :>
:> :> It's not nonsense. Failing to add known plaintext might help when
:> :> the attacker would not otherwise have a unique halting criterion.
:> :>
:> :> All he has to do is to guess keys ar random to stand an increased
:> :> chance of success with his improved halting criterion.
:> :>
:> :> This isn't difficult to understand. What is your problem with it?
:>
:> : We already beat it. Exhaustive search is trivial to defeat.
:>
:> Guessing keys is going to work some of the time, nevertheless.
: No. With a 256-bit key guessing has an insignificant
: chance of working even once.
You don't seem to share my idea of what "some of the time" means.
I would contrast this term with "never".
This point does not seem terribly interesting, though. We're agreed that
a brute force search of a reasonable keyspace is not a viable attack in
practice.
:> If you are arguing that the advantage offered by an improved halting
:> criterion is relatively small in the face of to difficulties imposed
:> by a 128 bit key space, then you would be right - *IF* there are no
:> attacks on the algorithm in question, and there are no other ways to
:> get hold of key material besides cryptanalyic attack. Since neither
:> of these can be known to be true there are other attacks besides
:> brute force or guessing whith which the ability to reject keys helps.
: If you need to disable known or chosen plaintext attacks,
: then use a system that can do so.
Unfortunately, this is easier said than done. You can't normally defend
perfectly against having your keys stolen - consequently, known plaintext
attacks may arise, no matter how secure your cypher, or how large your
key.
:> :> There you go with your "message spaces" again.
:>
:> : Yes. If you're seeking ideal secrecy without the OTP, then it
:> : turns out to be pretty important.
:>
:> Of course - but in the context of this discussion, individual messages
:> are what can be short - not whole spaces of messages. A single short
:> message in a message space of millions of lengthy messages is
:> liable to lack a concrete halting criterion - in the absence of
:> padding slip-ups.
: So your example actually does have millions of lengthy
: messages in the message space? [...]
Perhaps. I never said it didn't at any rate.
: But you think it's clue-ful to expect the messages will not have enough
: redundancy to resolve the key, because there are some short ones too?
Short messages won't have enough redundancy to resolve the key they are
transmitted with - because they are short.
I repeat again, I'm assuming the each message gets its own key.
:> :> Regardless of what you thought you were talking about, my
:> :> point still stands - short messages may not contain enough
:> :> entropy to allow a unique halting criterion. If you pad them
:> :> out with lots of zero bits, that may make the difference
:> :> between having a single unique possible message, and
:> :> having many such possible messages.
:>
:> : And your point is still nonsense. Halting criteria is no
:> : problem. Use a large enough key.
:>
:> Your objection appears to be nonsensical and contradictory! ;-)
:>
:> Using a large enough key *makes* halting criteria a problem.
:>
:> Your whole argument to date has been that the attacker can
:> always get hold of a halting criterion, even without padding.
:> If you now say "use a large enough key" to ensure no halting
:> criterion exists, you seem to be sabotaging your own argument.
: Ah, I should have been more specific. Use a key large
: enough that even with a halting criteria key-trial is
: useless.
There's no such key size (much short of using an OTP). Key spaces can be
reduced to searchable spaces by any number of non-cryptographic means,
including espionage, theft, component failures, and carelessness.
:> : Note that the one-bit followed by enough zeros to fill the
:> : block differs trivially from a bijection.
:>
:> There's a categorial difference - one is a padding scheme
:> - and the other is a mapping between two sets ;-)
: How does the way you choose to categorize them limit
: an attacker?
Sorry. I was just being pedantic. Don't bother to treat the question
seriously.
:> : Any message that does not end with an all-zero block is the padded
:> : image of some bit-string.
:>
:> Sounds a bit wasteful. Why not do what you suggested and
:> use "a one-bit followed by enough zeros to fill the block."
: I think this is a mis-communication again.
Misunderstanding, more like - on my part.
:> Better still, why not use a bijective mapping between
:> the set of 8-bits files, and files with the desired block
:> size.
: One could. The fact that it's bijective between those
: two sets does not mean that it doesn't add redundancy.
Hmm. It's true that individual messages /could/ become longer and much
more redundant - and that this could happen in a systematic way.
However, this is a thorny region that I'm not keen to enter into.
I think you could use a simple mapping and get maximum and minimum bounds
on any contraction or expansion, which - together with the bijective
property - would satisfy most that no such funny business was occurring.
: Not to worry though - real world message spaces have
: a lot of redundancy anyway, so our ciphers are designed
: to handle it.
As best they can. Our cypher's can't possibly be designed to
resist key theft, though. By contrast, decreasing message
redundancy can sometimes help defend against that.
:> :> : Very short messages happens frequently; for example an
:> :> : encrypted telnet session often sends individual key-strokes.
:> :>
:> :> : Do you know someone sending very-small messages with a new
:> :> : small key every time?
:> :>
:> :> I believe you can send messages of any size with PGP.
:>
:> : Yes, I noted public key systems in the previous post, and that
:> : they have a unicity distance of zero, so no message is short
:> : enough.
:>
:> You mentioned symmetric key distribution using PK systems.
:>
:> Once a symmetric key has been distributed, what then?
: Then you are already among the "some people" in:
: It is true that some people are prepared to trust
: security based on the percieved difficulty of performing
: certain mathematical operations, rather than security
: based on an information theoretical lack of ability to
: determine whether keys are correct.
Indeed. Use of public key systems seems destined to rest on one-way
trapdoor mathematical functions - and not information-theoretic secrecy
considerations.
[...]
:> : And do you actually know anyone sending only one message with
:> : each PGP key?
:>
:> With each PGP *session* key? Yes.
:> AFAIK, everyone who uses PGP does this.
: So if you strip off the public key encryption, then
: send the session key encrypted messages, and transport
: the unique session key by some out-of-band channel,
: then for very short messages you would have a case
: where the messages do not cover the unicity distance.
: Do you know anyone who does that?
No - but you have a case where the unicity distance is exceeded
without that - just consider the unicity distance relative to the
symmetric key - on the assumption that this is the weaker component
of the system.
It matters little if there's a key which could be verified as unique
hidden in a PK cryptosystem - if you have no attack on that system,
and no practical way to determine if a particular symmetric key is
being encrypted with it.
:> :> I was saying that some attackers might not have the information
:> :> necessary to mount the attack you suggested. Consequently,
:> :> defending against their (weaker) attacks may still be worthwhile.
:>
:> : As I wrote in the snipped part, one has to defend against
:> : chosen-plaintext in this case, where bijective padding is
:> : useless at best. Expecting that the message space won't have
:> : enough redundancy is clearly wrong if _any_ adversary knows
:> : the plaintext.
:>
:> Obviously. Equally obviously, the contingent "if" need
:> not be true.
:>
:> : This example fails big.
:>
:> No - you've still just failed to grasp it.
: Not through lack of trying. Where did I misunderstand?
I'm not /exactly/ clear what's going on in your mind. One possible guess
is that you're applying the principle that looking after powerful
attackers deals with weaker ones, so you're concluding that an attacker
with minimal known plaintext is not worthy of consideration.
: These are intercepted encrypted messages. The plaintext of your
: messages is the intercepted ciphertext. You cited this as a
: case in which it would be reasonable (non-clueless) to
: expect our messages did not cover the unicity distance of a
: conventional cipher.
Yes.
: If we're intercepting these messages, an adversary supplies
: our plaintext. We have to expect not only known, but chosen
: plaintext attacks. Bijectively transforming chosen
: plaintext just means that the attacker can choose every
: bit of the post-padded message.
Yes. However, not all possible adversaries will be able to do that.
Of those that can, if they can /also/ reduce the keyspace to managable
proportions, all is lost.
However, we can still defend against attackers who don't have the
knowlegde of the original plaintexts, but do have a keyspace reduction.
Simply avoiding giving these attackers known plaintext can defeat these
folk under some circumstances.
It may be of value to identify forwarded encrypted messages, even if they
can't decode them immediately.
Obviously you should try to defend against having your keyspace reduced
as well - but this is not a problem with a purely cryptographic
resolution.
[...]
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Hat: Baldness cure.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 5 Nov 2000 14:17:40 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
>:>One remaining issue seems to be that you can't be encrypting
>:>0x00000000 - so one cyphertext will go missing (unless you are
>:>careful). Also what happens if you encrypt to 0x00000000 (not a FO
>:>file)?
>
>: Actaully he can be encrypting that. YOu are confusing normal
>: 8-bit files with fintiely odd files. [...]
>
>I wasn't doing that - but I didn't realise 0x00000000 counted as a FO
>file.
It doesn't count as a FO file. By defintion the finitely odd (FO)
file has at least 1 bit the last one bit a fintite distacne away from
the start. If your talking about a file that is a single byte or
group of bytes that is all zero. The finitly odd file which is infinite
in length is the one obtained by representing the file in a stream
of as many zeros as in the bytes followed by a single one bit followed
by an infinte number of zeros.
But just as Cantor ( maybe wrong name number years since college) showed
that there is the same number of numbers in a full counting system
1 2 3 4 as in a purely odd counting system 1 3 5 7 one can map in
a "fully bijective way" from either one to the other. This particular
infinity is the same infinite as is in 8bit byte files and finitely
odd bit streams. One could easuly define a 1-1 fully bijective mapping
by dropping the fist sysmbol ( or fintie number in either set) and still
get a 1-1 mapping. So it is possible to include the all zero case as
a special finitely odd file. I choose not to. I assume Matt did like
wise but it is not a requirement in that only the 1-1 mapping between
the 2 infinte sets needs to be considered. And which one choosen by the
user is of little concern if the set is choosen such as Matt did so that
any possilbe 8-bit files can be considered an input file or an output file.
with evey possiblity used.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 5 Nov 2000 14:32:08 GMT
[EMAIL PROTECTED] (Bryan Olson) wrote in
<8u3cip$vr7$[EMAIL PROTECTED]>:
>Tim Tyler wrote:
>> Matt Timmermans wrote:
>>
>> : Because final mapping (tivial decoding) from FOstreams
>> : to byte-granular files is bijective, the encryption can
>> : perform any reversible operation on the FOstream without
>> : changing the bijective nature of the entire process,
>> : including operations that change the number of significant
>> : bits.
>>
>> I think this is what I didn't grasp. It's obvious, really ;-)
>
>But subtle. I had to sketch a proof to convince myself the
>encryption is bijective on finitely odd streams. A key point
>is that for streams of more than 128 (significant) bits, the
>transformation preserves the (significant) bit length. For
>streams of 128 or fewer significant bits, it's not length
>preserving but will never map to a stream of more than 128
>(significant) bits. Thus we can separately show it's
>bijective on the set of <=128-bit FO streams, and bijective
>on the set of >128-bit FO streams.
>
>
>> One remaining issue seems to be that you can't be encrypting
>> 0x00000000 -
>> so one cyphertext will go missing (unless you are careful).
>> Also what happens if you encrypt to 0x00000000 (not a FO file)?
>
>The name "finitely odd" and the comments in the code may be
>misleading. All zeros is a finitely odd bit stream.
>"Finitely odd" means "not infinitely odd".
>
I hope I anwsered the last point raised in the response to Tim.
However before your mind decides it is not possible. And I think
many people as they learn of this will decide its possible then
impossible a few times before it sinks in. I was wondering what
you now think of it as a concept the idea of having a fully bijective
compress with Rijndael. One could always add random later if that
is ones GOD. But do you see the usefullness of this as a basic
component? I belive that even the people who invetned Rijndael think
its use in a compressor in full width mode and still being
fully bijective is impossible. At least that is what they currently
are saying in email to me.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: RSA vs. Rabin
Date: Sun, 05 Nov 2000 15:58:44 +0100
Thanks to Fritz Schneider <[EMAIL PROTECTED]> who pointed out
a scanned version of the the January 1979 Rabin paper online at
<http://hdl.handle.net/ncstrl.mit_lcs/MIT/LCS/TR-212>
The Postscript returned by the server is only mostly good, but the
MIT archivists have fortunatly kept the original scans, which I
massaged a bit. If someone is interested, email me and I'll send
a 582kB PDF which is a third of the PS, and of better quality.
The paper describes a public key scheme using the public
transformation
x -> c = x(x+b) mod n
for n = p*q and some public constant b, which can be 0.
Rabin points out the need of padding for signature applications:
"By convention, when whishing to sign a given message, M,
(the signer) P adds as suffix a word U of an agreed upon length k.
The choice of U is randomized each time a message is to be signed.
The signer now compresses M1 = MU by a hashing function to a word
C(M1) = c, so that as a binary number c<=n; (..) The computation of
C() is publicly known, so that c = C(M1) is checkable by everybody.
(..) Without the suffix, an adversary may attempt to feed to P
messages M for his signature, hoping to learn the factorization of
n from the solution of x(x+b) = C(M) mod n , which will be produced
by P as his signature. Actually, this does not seem to be a serious
threat because of the hashing effected by C(M)."
So Rabin actually describes a signature scheme with random padding
and full-domain hashing and proves security of the encryption scheme
(though not the signature scheme).
What a great paper ! January 1979 !!
Francois Grieu
------------------------------
** 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
******************************
