Cryptography-Digest Digest #137, Volume #11 Wed, 16 Feb 00 21:13:01 EST
Contents:
Re: Somebody is jamming my communications -- this has been happening at least in
three separate communicat (UBCHI2)
Re: Does the NSA have ALL Possible PGP keys? (David Hopwood)
Re: source code export laws (Andru Luvisi)
Re: Question about OTPs (Mark VandeWettering)
Re: Question about OTPs (Tim Tyler)
Re: Disregaurd last post Re: Newbie - Determining encryption Bit Level ("Joseph
Ashwood")
Re: NIST, AES at RSA conference (Bryan Olson)
Re: Which compression is best? (Tim Tyler)
Re: Which compression is best? (Tim Tyler)
Re: Question about OTPs ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: Somebody is jamming my communications -- this has been happening at
least in three separate communicat
Date: 17 Feb 2000 00:14:42 GMT
Leave the poor guy alone. Why do you pick on mentally disturbed individual.
You are pretty pathetic.
------------------------------
Date: Wed, 16 Feb 2000 02:35:10 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Does the NSA have ALL Possible PGP keys?
=====BEGIN PGP SIGNED MESSAGE=====
"Douglas A. Gwyn" wrote:
>
> W A Collier wrote:
> > They can "really want to" all they like, but they cant change fundamental
> > nature of NP-Hard and other mathematic concepts upon which modern crypto
> > is based. Try reading up before you make a jackass out of yourself
> > again.
>
> Be careful when you say such things -- the security of any actual
> instance of a cryptosystem cannot be based on "NP-Hard"ness.
It is still an open question whether it is possible to construct a
cryptosystem for which almost all cases are effectively "as hard as"
the worst case. Atjai-Dwork was an attempt at that; it was broken because
the chosen problem turned out to be too easy even in the worst case,
not because this is impossible in principle.
OTOH, AFAIK no existing secure cryptosystem is based on an NP-hard problem.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKoMyTkCAxeYt5gVAQGwfgf/SkCvYKNiVE04E8Ii+D4R6WjzZkwPo4bb
w0Z3ujF4z4TUOQuWTpS/iW7V251dbFLd9xEtFSoERCGbNeP9mgpaxOHdQm0Z9WNi
rJgkL6PobZMLGa+ajdDrJchO2TzsXce3wcmp8Xdnd7OJNq7HQhBiJEbYzQKyufR/
KNakS74MlW7SNJSZhwm+lKIRQq3hNs6c05ykbwIrLD2NwpUChJ8oqa6zeOTvYEAV
vzfzzvXqYDYNL5hS94H90DMDmcRl3wbuXGUYgG5lwljUhYYenq8/93VTvX5Y4i47
DnGfvho5lePRDmRyrDuUX7rCtJsoZEVV2LQpeFzpxWpGTs8mI1PbJA==
=dTnQ
=====END PGP SIGNATURE=====
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: source code export laws
Date: 16 Feb 2000 16:14:30 -0800
[EMAIL PROTECTED] (wtshaw) writes:
[snip]
> The point is that the only difference between a crypto program and one
> that is not is probably in a few lines of code. And,those lines are
> nothing special to frame here.
It doesn't even have to be code. It can just be the way the program
is used. For example:
$ tr a-zA-Z n-za-mN-ZA-M
$ sed -e 'y/abcdefghijklmnopqrstuvwxyz/nopqrstuvwxyzabcdefghijklm/' \
-e 'y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/NOPQRSTUVWXYZABCDEFGHIJKLM/'
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Wed, 16 Feb 2000 16:50:48 -0800
Arthur Dardia wrote:
> Many people attempt to pack CD-ROM's with totally random data; however,
> then you must tell your recipient which offset to start reading the pad
> from. So, my question is this: for one message, so that I start at the
> 30,567,890 byte and the next I start tat the 30,567,889. While this is
> only one byte off, the ciphertext is totally different; however, how
> secure is this?
Not secure at all. You've taken one of the very best cryptosystems, and
turned it into something really trivial.
The crack proceeds as following: You can find the offset rather easily by
basically taking the two texts at different offsets, and XORING them together.
If the two streams are synchronized at the offset you've chosen, you get a MASSIVELY
different frequency distribution. In effect, you have two plaintext messages XOR'ed
together. Cracking such a thing is dead simple, you basically just take common words
and run them through the combined text, and see if real words pop out the other side.
You can't reuse any part of a OTP without seriously jeopardizing it's security. The
same error sometimes happens when people resuse seed values for stream ciphers.
Mark
> --
> Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
> PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://raytracer.org
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Feb 2000 00:41:13 GMT
Arthur Dardia <[EMAIL PROTECTED]> wrote:
: As we all know, many people are becoming interested in one time pads due
: to their "perfect" security system. Yes, while this system is perfect
: with totally random data and a "perfectly" secure way to transfer the
: pad-file, this is rare to come by.
I don't know about that.
A OTP fails against a complete known plaintext attack - which immediately
reveals the key.
Even with a good source of random numbers - and a perfect distribution
mechanism, without signing - or some better scrambling than XOR provides -
I don't think the system is at all "perfectly" secure.
It has about the best possible resistance to cyphertext-only attack,
that's all.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
"Bummer", said Pooh, as Tigger dropped the joint in the hooney jar.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Disregaurd last post Re: Newbie - Determining encryption Bit Level
Date: Wed, 16 Feb 2000 17:21:36 -0000
Well, if I'm reading it correctly (which I may not be since
I don't recognise the language)
We can't tell.
I'm reading this as:
65536 times:
if(first time)
data = SinLineEncrypt(data, key)
else
SinLineEncrypt(data, "external" +
stringVersionOf(number of times-1)
end 65536 times
It's slightly more complex, but that's roughly equivalent.
Given this we need to know what SinLineEncrypt does, and it
is in there that the strength of your proposal lies, if
SinLineEncrypt is strong then this segment will be strong,
but it is worth noting that your last 65535 encryptions are
useless, they can be undone without knowing the key, and are
on the outside of the keyed encryption, meaning that they
can be undone as fast as you can do them, and then you are
restricted to only one operation of SinLineEncrypt. If I'm
reading this incorrectly please tell me.
Joe
"Brian Bosh" <[EMAIL PROTECTED]> wrote in message
news:Kcpq4.1316$[EMAIL PROTECTED]...
> This is the main code for encryption in my program...
> IF Action = 1 THEN
> FOR X = 0 TO 256 ^ 2
> IF X = 0 THEN SinLineEncrypt TE$, Key$
> IF X > 0 THEN SinLineEncrypt "%/E", "external"
+STR$(X)
> NEXT X
> END IF
>
> By my calculations, this number is minute. Can you tell me
how strong of
> encryption this would offer?
>
> Brian
>
>
> "John Savard" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Brian Bosh" <[EMAIL PROTECTED]> wrote, in part:
> >
> > >DAMN IT, I'm not thinking!
> >
> > >Like Secure sites like Amazon use 128 Bit encryption
(Not KBPS!)!
> >
> > Ah, if that's what you mean, 128 bit encryption means
that the _key_
> > used for the encryption is 128 bits long. More
specifically, the key
> > for the symmetric-key portion of the encryption is
128-bits long.
> >
> > That means that there are 2 raised to the 128th power
possible
> > different keys for that encryption, and so that is a
measure of how
> > hard it is for someone to decode your messages just by
guessing the
> > right key or trying every key till they find the right
one.
> >
> > 2 to the 10th power is 1,024, so 2^120 is about 10^36,
so 2 to the
> > 128th power is more than
> > 256,000,000,000,000,000,000,000,000,000,000,000,000.
> >
> > John Savard (jsavard<at>ecn<dot>ab<dot>ca)
> > http://www.ecn.ab.ca/~jsavard/crypto.htm
>
>
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Thu, 17 Feb 2000 01:20:19 GMT
Terry Ritter wrote:
>
> Bryan Olson wrote:
>
> >Terry Ritter wrote:
> >> I dispute that. You have taken my words out of context and
> >> misrepresented my position; while the words are similar, their
meaning
> >> is not.
> >
> >You miss the point. The greatest misrepresentation of
> >positions has been your incessant ridicule of the
> >"unscientific" reasoning of others. Over and over you
> >lectured on how there is no mathematical proof of security
> >to an audience that did not claim there is.
>
> When one chooses to argue semantics, it is usually because the
> fundamental position is obviously wrong, as it is here.
You choose to miss the point. The reasoning you offer
to support your proposals is no more rigorous nor more
scientific than positions you ridiculed. See:
http://x25.deja.com/[ST_rn=ps]/getdoc.xp?AN=580223084&search=thread&CONT
EXT=950746288.1310523408&hitnum=106
for concrete examples.
> Of course, as long as you don't explicitly *say* that you support the
> result of AES, you can say "Hey, I didn't say anybody should *use*
> it!" It's sad, really.
When the AES is final, I expect to advocate using it.
> It is clear to me that you think all we need to do is have some
> academics check out candidate ciphers (even though we really don't
> know how much effort anyone in particular has put into doing that),
> then society should use the result.
>
> Of course there is no science or logic which allows us to extrapolate
> cryptanalytic negative results into strength, or probable strength, or
> even trustable strength.
Nonsense. In
http://x33.deja.com/[ST_rn=ps]/getdoc.xp?AN=474923670.3&search=thread&CO
NTEXT=950747044.532021269&HIT_CONTEXT=950746963.531824649&hitnum=118
you agreed that the approach is scientific, and made a
semantic argument against calling it "validation". So
how are your own schemes validated?
> So instead of trying to innovate ways to minimize or eliminate some
> attacks, or minimize the consequences of successful attack, you prefer
> things the way they have been. You would have all of society depend
> upon a few ciphers as though that were no risk at all, or there is no
> way to reduce that risk.
No, I recognize that the AES designers and analysts have
already taken significant steps to minimize or eliminate a
variety of attacks, and try to improve the odds. The AES is
not about accepting what we have.
[...]
> >We only know what attacks _we_ favor, while it is the
> >attacks that may hurt us are those that our adversaries
> >choose. Are we justified in assessing what an adversary can
> >do and might achieve based on our understanding? If not,
> >then your logic above still yields nothing.
>
> Nonsense. By adding things beyond the cipher (such as using multiple
> cipher levels, and partitioning plaintext for protection under
> different ciphers, etc.) we do not just reduce attacks, we complicate
> or eliminate whole classes of attacks, and reduce whole classes of
> risks.
Many of the AES entries have levels beyond what they seem to
need for security. Partitioning plaintext will not help
unless it partitions the intelligence content, which random
partitioning will not do in most practical situations.
> You owe *everyone* here a deep, heartfelt apology (which I expect to
> never see) for your continued attempts to hide your weak position by
> not stating it so that you do not have to defend it.
I've posted many, many positions, as of course you know.
> It is clear that you are not advocating not using cryptography. And
> if you don't like adding things beyond the cipher, it seems reasonable
> to assume that you think the cipher alone is enough. So your position
> is that -- even though you cannot prove that particular cipher is
> secure -- you are willing for society to take the risk that you are
> wrong. Gee, how academic of you.
A multi-cipher is a kind of cipher; it's in no way "beyond"
and you can't prove it's secure either. I'm a long-time
advocate of conservative design, and building a security
margin by concatinating three ciphers which individually
seem secure is one arguable technique.
[...]
> >> Such reasoning can be seen as a form of mathematical fallacy which
is
> >> often presented in early algebra, the "equality" of two infinities:
> >> True, a cipher has infinite possibilities for failure, and true, a
> >> multi-cipher also has infinite possibilities for failure, but it is
> >> false that those two infinities are equal.
> >
> >Perhaps you missed the point in your algebra class too. The
> >cardinality of the rationals is equal to the cardinality of
> >the integers, while the cardinality of the reals is greater.
> >They are all precisely defined and the results are provable.
> >How do you define the infinities you talk about for a cipher
> >and multi-cipher, and what is your proof that they are not
> >the same?
>
> This is a classic instance of your deliberately slanted logic. It is
> just embarrassing. You really have no shame at all.
Asking you to define the terms you used and justify your
claim is slanted logic? I was simply illustrating that the
precise terms don't really apply; it was a handwave.
> For those still with us, it is false to reason that a cipher alone
> must be just as secure as that cipher with added levels of security
> simply because there is no proof for either. We do know some attacks,
> we do know that those attacks are complicated or eliminated by some
> additions, and if we have those additions, we have strengthened the
> cipher against those attacks. And the additions often function
> against whole classes of attacks.
And it is false to ignore the reasoning of the AES designers
and consider every "cipher alone" as the same. They have
already worked to defeat the attacks they know and add
protections likely to defeat whole classes of attacks. Mars
has different kinds of rounds; Serpent has twice the rounds
that seem necessary. What part of your argument for
tripling ciphers would not apply to a cipher with an
internal structure that happens to already be a triple
cipher?
--Bryan
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Feb 2000 00:48:59 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
: wtshaw schrieb:
:> Runu Knips <[EMAIL PROTECTED]> wrote:
:> > Compression adds a KNOWN and FIXED structure which makes attacks
:> > easier, not harder.
:>
:> Ah...the problem is that larger redundant structures are so much easier to
:> spot then smaller; [...]
: A cipher which is not secure without compression will not become more
: secure when you compress the data. [...]
Not normally. It /could/ do - if the file compressed target files to
a point where they were as long as the key (or so that they became
short enough to prevent whatever attack is known).
: You only do a simple transformation of the input, which in itself is
: not hard to "guess" (as a rule, that transformation is know), and
: follows fixed rules. So how could that add any real security ?
It /can/ do. Because it's an unkeyed transformation it does not follow
that its security value is zero.
Diffusion may be unkeyed, yet it is very effective at preventing attacks
based on known partial plaintexts.
In either case, it matters not that the attacker has the algorithm used
to hand.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Death is the cure of all diseases.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Feb 2000 01:18:42 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
: !> Runu Knips <[EMAIL PROTECTED]> wrote:
: !> : Tim Tyler wrote:
: !> :> Runu Knips <[EMAIL PROTECTED]> wrote:
[snip]
: !> : Compression adds a KNOWN and FIXED structure which makes attacks
: !> : easier, not harder.
: !>
: !> This is a description of many crap compressors.
: Wrong.
Hmm. I don't see the problem with my claim :-(
: This is how ALL compressors work. No matter if simple RLE or
: Huffman or ZiffDavis or whatever. Their output always follows rules.
Their "output always follows rules" in the sense that it is
deterministically derived from the input text.
That does *not* mean you can write a program that identifies compressed
files as such.
It /should/ be easier to identify the original documents than their
compressed versions (when rejecting bad decrypts). If this is not the
case, you /may/ be using a dud compression program - not suitable for
application before encryption.
: !> You don't show any signs of having followed the compression
: !> discussions in this forum.
: Oh, you are the only people in the world which know about cryptology
: and compression?
Of course not. However, the discussion here has covered the points you're
raising in the past. More familiarity might have saved you your queries.
: Interesting. No, I of course read this in books about cryptology.
Most of the books about cryptography I've seen appear to be out of date in
this area. The coverage in (say) Applied Cryptography is /extremely/
cursory. I count fourteen lines in a 700 page book :-(
However, what you're saying is /partly/ correct.
Compressing badly /can/ help attackers more than it hinders them.
However, just because some compressors are less-than-ideal for
cryptographic purposes, it does not follow that you can tar *all*
compressors with the same brush.
Yes - exercise caution when choosing a compressor - but don't say
"never compress".
The benefits of good compression are significant - and there need not be
important drawbacks.
: !> Compressors exist that add absolutely zero bits of information to the
: !> files they compress. That represents an absence of added structure
: !> - and since the files are shorter, they're rather likely to have less
: !> "KNOWN" and "FIXED" structure than the original texts.
: !> It's still /possible/ that such compressors will have small areas of
: !> concentrated, patterned information, that's easier to target than an
: !> equivalent section of the original plaintext - but the better the
: !> compression ratio, the less likely this is - since the shorter the
: !> files are the greater the entropy-per-bit and the closer they become to
: !> apparently random sequences.
: Nope [...]
Yep.
: [...] you can always decompress and check against the first set of rules.
That may not necessarily help. All (or most) decompressed files
may exhibit the characteristics being searched for in the original text.
This might happen if the compressor were very efficient.
Note also that you can only be sure of being able to do this this if you
have the whole file decrypted. Without the whole file the attacker may
not be able to begin to decompress.
This ability to delay plaintext analysis of the first blocks until the
last ones have been decrypted is another securtity benefit of some
compression schemes.
: In a simple brute force attack, this would make the
: attack somewhat slower, but only by some small and fixed factor.
Compression does often have this effect. However, it *can* have more
significant effects. Look at the effect on partial plaintext attacks,
for example.
Where, with no compression, keys can be immediately rejected, with
compression, they often cannot be. This can easily make the difference
between the attacker being faced with millions of possible decrypts - or
only one possibility.
: You see, that is the simple problem like in the enigma - many
: of the "improvements" of this machine actually helped the enemy
: to break the enigma code.
Adding "good" compression would be better compared to adding a rotor.
You can be pretty damn sure that it will hinder the enemy a lot more than
it will help him.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
1024x768x256 - now that's one mean woman!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Wed, 16 Feb 2000 22:40:13 GMT
"Douglas A. Gwyn" wrote:
> ... leaving just the differenced PT ("delta stream").
I should perhaps point out that "delta stream" has
another meaning, differencing a CT against itself,
but that's conceptually similar, just as
autocorrelation is related to cross-correlation.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Wed, 16 Feb 2000 22:43:32 GMT
Mok-Kong Shen wrote:
> I am ignorant of what the C standard specifies. Question: Does
> 'binary' require the file to be multiple of words or just any
> multiple of bytes will do?
The latter.
For a binary stream, also, the file position indicator (used
with fseek and ftell) measures position in bytes, unlike the
case for text streams in some implementations (where about
the only thing you can do with the f.p.i. is use it to get
back to the previously recorded position).
------------------------------
** 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
******************************
