Cryptography-Digest Digest #104, Volume #11 Sat, 12 Feb 00 05:13:00 EST
Contents:
Re: UK publishes 'impossible' decryption law (wtshaw)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Terry Ritter)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Terry Ritter)
Re: BASIC Crypto Question (wtshaw)
Re: need help with a basic C++ algorithm (wtshaw)
Re: Period of cycles in OFB mode (Terry Ritter)
Re: Twofish vs. Blowfish ("Douglas A. Gwyn")
Re: Which compression is best? (Thomas Pornin)
Re: Continually Secure Password/Pin (Thomas Wu)
Re: BASIC Crypto Question (Johnny Bravo)
Re: Does the NSA have ALL Possible PGP keys? (Highdesertman)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Sat, 12 Feb 2000 00:18:09 -0600
In article <881rin$cc6$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mike Eisler) wrote:
> As was pointed out, under the UK law, you are guilty till proven
> innocent.
>
The French and Spanish have finally defeated the British. Let's see...how
many centuries did it take?
--
If Al Gore wants to be inventor of the internet, complain that he
did a lousy job. If he admits to not doing much, complain that he
is a slacker. Now, do we want him in charge of security?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Sat, 12 Feb 2000 07:50:26 GMT
On Fri, 11 Feb 2000 18:21:58 -0800, in
<882g5q$k0k$[EMAIL PROTECTED]>, in sci.crypt "r.e.s."
<[EMAIL PROTECTED]> wrote:
>"Terry Ritter" <[EMAIL PROTECTED]> wrote ...
>[...]
>: My main reason for using combiners is to complicate or eliminate
>: known-plaintext or defined-plaintext attacks. Normally, in a stream
>: cipher using an additive combiner, known-plaintext (or just "guessed
>: plaintext") will immediately reveal the keystream or confusion stream.
>: Then the opponents start to work on the key generator. A keyed
>: nonlinear combiner at least prevents easy access.
>:
>: The reason for having *Latin square* combiners is to prevent leakage
>: through either input port. We certainly don't want leakage from
>: plaintext. But if we choose things at random I think it would be
>: common to find some amount of correlation between output and key under
>: known-plaintext conditions. Then the opponents can at least start to
>: work on the key generator.
>[...]
>
>Additive combiners (XOR or modular addition) are, of course,
>a subset of Latin Square combiners.
Yes, and are clearly linear as mod 2 polys (XOR) or mod n (n probably
= 2**m for addition). This is not just theoretical weakness.
>I've looked at your
>on-line Glossary to see what you mean by "nonlinear combiner",
>but the definition of "linear" is not really clear to me in
>this context. The confusion is surely mine, but I have trouble
>interpreting the above paragraphs because I'm not sure where
>you draw the line between linear & nonlinear combiners. E.g.,
>do you consider all Latin Square combiners to be linear?
I think that's a very reasonable question, if perhaps less easily
answered. In my experience, the distinction between "linear" and
"nonlinear" is not as clear as one might like throughout cryptography.
Presumably any form of linearity counts, and there can be many such
forms.
We might consider permutation itself to be linear, but I think to do
so we must have access to the whole permutation. If we know only part
of it, or none at all (e.g., one term of larger equation), we may not
be able to manipulate this "linearity" in a useful linear way. The
S-boxes in DES are composed of permutations, yet they are always
called "nonlinear."
One way to think about linearity is the ease with which one can
extrapolate from a known transformation (from domain value to range
value) to expose an unknown transformation (given some other range or
domain value). This is clearly trivial with XOR or (+), less trivial
with a random permutation of 256 values, and much less trivial when
multiple keyed transformations are involved in an equation.
I have also done some work comparing permutations in Latin squares
with respect to "Boolean function nonlinearity." This is basically a
distance measure with respect to "affine Boolean functions" or "Walsh
functions," for any particular bit-position in such a table. (An
"8-bit" permutation with 256 elements would have 8 Boolean function
nonlinearity values, of which we would typically take the smallest as
the indicator of the weakest bit in the permutation.) Each result
tells us how well a bit-string can be modeled by the best linear
approximation to that sequence. For the 256-bit sequences generated
by random "8-bit" permutations, typically something like 100 bits must
change to reach the linear Boolean function which is closest to any of
the 8 measured bit sequences. I see this as one form of strength.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Sat, 12 Feb 2000 07:51:28 GMT
On Sat, 12 Feb 2000 01:36:12 GMT, in <882ded$6q9$[EMAIL PROTECTED]>, in
sci.crypt zapzing <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Latin squares are really only useful if the input alphabet and key
>> alphabet are the same size. The DES S-boxes don't have the same sizes
>> but seem to work OK.
>>
>>
>
>Well. actually that is true by definition,
>since a latin *square* must be square.
>But your post gives me an interesting idea.
>What if we generalize it to a latin *rectangle*?
I suppose much would depend upon how it is used. In many cases it
might be better to use multiple Latin squares: If we just drop in
multiple occurrences of values at random, we are almost guaranteed to
have some grouping which will highlight some locality of input values.
This would leak more information than would happen if groupings were
minimized by the enforced spacing of different tables.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: BASIC Crypto Question
Date: Sat, 12 Feb 2000 00:47:33 -0600
In article
<[EMAIL PROTECTED]>, Eric
Lee Green <[EMAIL PROTECTED]> wrote:
>
> > Are there some ciphers more suited to say image and formated documents
> > encryption, whereas others more suited to text...Or is it all bits and
> > bits...nothing else to consider?
>
> Bits are bits. About the only thing to consider is that stream ciphers
> (whether implemented via a block cipher and CFB, or not) are easier if you're
> talking about network streams, whereas block ciphers tend to be more secure
> due to the keys issue. If you're talking files, though, a data length word at
> the beginning and then chopping off the result at that # of bytes will take
> care of that for block ciphers.
>
Bits are popular, but not the only information unit that can be used.
Many have been so conditioned by the necessity to maximize efficiency for
use with old slow clocks that they see no other way. But, this is just
choosing to be blind to the efficiencies and capabilities that might be
done if some other unit is used. Classic crypto does use several types of
information, and more refined ciphers can also.
Yes, there is more to consider, lots more. What to call these other
units? Trits for base 3 is an example, and bits have nothing to do with
them, not even a subset. Since the ratio is proportional to the logs of 2
and 3, a trit is equal to 1.5849625 bits. It gets more interesting with
other sized information units as each has special attributes that can be
utilized.
--
If Al Gore wants to be inventor of the internet, complain that he
did a lousy job. If he admits to not doing much, complain that he
is a slacker. Now, do we want him in charge of security?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: need help with a basic C++ algorithm
Date: Sat, 12 Feb 2000 01:03:25 -0600
In article <882agf$4s7$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> What is Rot-47 or Rot-13 or Rot-5. How does it work?
>
I favor ROT45, disregarding some of the characters at the top, because it
places one of the alphabetic series squarely in the middle of the series
of 90 values. These words become:
v 94IBE %"'abY 7<FE8:4E7<A: FB@8 B9 G;8 6;4E46G8EF 4G G;8 GBCY 5864HF8 <G
C?468F BA8 B9 G;8 4?C;458G<6 F8E<8F FDH4E8?L <A G;8 @<77?8 B9 G;8 F8E<8F
B9 f] I4?H8F[ ';8F8 JBE7F 586B@8g
As an optional technique, simply inverting a set is a classic way of
encrypting also. These words in INV45 become as follows:
Z( :- ,+'2,-:/ '683-2*&6o (2.+/" 2-%6)'2-4 : (6' 2( : 8/:((28 $:" ,5
6-8)"+'2-4 :/(,m G36(6 $,)7( 2- RMEgf 968,.6 :( 5,//,$(a
Notice that as long as you don't use capital letters, nonalphabetic
characters result from alphabetic letters.
--
If Al Gore wants to be inventor of the internet, complain that he
did a lousy job. If he admits to not doing much, complain that he
is a slacker. Now, do we want him in charge of security?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Period of cycles in OFB mode
Date: Sat, 12 Feb 2000 07:52:21 GMT
On 11 Feb 2000 19:18:37 -0800, in
<882jed$b5p$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Paul Koning <[EMAIL PROTECTED]> wrote:
>> That's why I've always liked counter mode. Its cycle size is
>> obvious (2^64).
>
>But it is worth mentioning that counter mode also starts to exhibit
>some regularities (a birthday paradox-like issue) after about 2^32 blocks,
>so it would only be prudent to change keys well before that point.
>(I'm assuming you're using a block cipher with 64-bit block size.)
>
>> It also has the nice property that you can
>> parallelize it for higher speed.
>
>Yup. From my point of view, this is the big win of counter mode.
In contrast, I have always been worried by "counter mode."
Clearly, an arithmetic count sequence is very regular: The lsb
changes every time; the next higher bit half as often, and then only
when the lsb changes to zero. That is a lot of statistical
bit-position information which may be amenable to frequency and phase
detection techniques.
Now, if the block cipher is perfect in practice, all this should not
be a problem. But practical block ciphers may not wrap one edge to
the other, and bit-diffusion from an edge of the block may not be as
good as we would expect elsewhere. The extremely strong counter
signal may thus expose cipher problems which would otherwise be
hidden.
It seems to me that this is yet another way of asking for trouble,
especially since a fairly easy alternative exists: Simply use a
polynomial counter rather than arithmetic counting.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Sat, 12 Feb 2000 08:34:26 GMT
"SCOTT19U.ZIP_GUY" wrote:
> How would one prove that the key-generator got lost or overlooked
> is it not possible this over sight occured due to the NSA greaseing
> the right palms. I think it is a safe bet that many of the "flaws"
> in the micro soft junk is there becasue the NSA wants them there.
You have no right to make such accusations without evidence.
It is easy enough to talk to the developers of said software;
have you done that? What did they say? Why would we believe
your wild accusations over the word of those developers?
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Which compression is best?
Date: 12 Feb 2000 09:02:02 GMT
According to Tim Tyler <[EMAIL PROTECTED]>:
> So, the question arises: do you *know* your entire system is not weak.
If you want a simple answer: *yes*. This is a matter of adequacy between
the goal and the means. When I use an encryption method, I intend to
defeat attackers who fit into my model: I mean, I do not take into
account quantum computers or biomolecular processors, since people
mastering these advanced technologies are obviously able to put a
miniaturized video camera into my computer screen, or maybe my own eyes.
Moreover, there is a limit to speculation, and beyond that limit it is
no longer pertinent. If I want to be protected against the Men In Black,
I need help from aliens, because I cannot even imagine what they can do.
> Other people should obviously concern themselves with compression,
> given that very good compression can in principle make an analyst's
> task well-nigh impossible.
How do you know that any compression, even if it is very good, will
annoy an analyst who, in your attack model, can defeat DFC with a
192-bit key ? (I take DFC, one of the AES candidates, as an example of
an algorithm I trust, since I contributed to its development). In my
point of view, compression is not worth the effort; increasing the key
size is a much cheaper and more efficient tactic (although I consider
that beyond 96 bits, we jump from security to science-fiction).
--Thomas Pornin
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Continually Secure Password/Pin
Date: 12 Feb 2000 01:27:58 -0800
Paul Crowley <[EMAIL PROTECTED]> writes:
> As far as I can tell, SRP (http://srp.stanford.edu) is the only
> protocol that has *all* the nice properties for remote password
> login. So what I want to see is a W3C standard for SRP authenticated
> login atop HTTP. I don't know enough about HTTP to know whether this
> is possible, though.
One idea that I've floated around is an improvement on HTTP/Basic and
MD5 Digest Authentication, in which SRP is used to verify the user's
password securely. Nowadays, a smarter solution might be to use SRP
to bootstrep a secure session key for use with SSL/TLS. This would
offer, in many cases, security that is stronger and more convenient
than client-side certs, since there would be nothing to crack on the
client side and no private keys to copy around.
> Of course, you wouldn't want to go through SRP every time you fetched
> a Web page: you'd want to negotiate a stronger secret with the server
> that you could use to get a non-PK based login the second time.
> Actually, S/Key style hash preimages like you propose might be just
> the thing! The disadvantages people have identified are less of a
> problem with a hybrid protocol, where the secret used is much stronger
> than a password.
> --
> __
> \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
> /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: BASIC Crypto Question
Date: Sat, 12 Feb 2000 04:52:07 +0000
On Fri, 11 Feb 2000 18:51:55 GMT, [EMAIL PROTECTED] wrote:
>Am I right to assume that Ciphers (Block and Stream Ciphers) work at the
>bit level , regardless of what the data structure/format is of the
>document file.
Technically, the norm is to work on a multiple of 8 bits at a time, i.e.
"bytes" as most languages can easily read byte sized units from a file.
Another norm is working on multiples of 8 bytes, though there is no real
requirement for this (recent 128 and 256 bit block ciphers). Stream
ciphers of course work on a single byte at a time. RC4 is simple to
implement from just the description, has good help available on the web,
and is secure enough to protect credit card data on the WWW.
>This would imply that with the same cipher (DES, IDEA, Blowfish), I can
>encrypt documents, images ( .jpeg, .jif, .bmp ) , .wav files, email
>attachments, word documents, .xls documents, .pdf, .ps,
>.tar, .gz, .zip...whatever... is that right? The cipher only sees
>bits...
Yes, treats everything the same, the cipher couldn't care less,
everything is read in as binary data and output the same way.
>So for an email text with an attachment, I would encrypt both seperately
>and lump them together? or should one merge two files of diffetent
>formats together in one file? .
Only if your cipher program has a method for dividing them correctly
when finished, otherwise you might be better off just encrypting each
separately. Just attach the encrypted message and file to a nondescript
email so the news reader doesn't go ballistic if it encounters a binary
message. This will also help with the problem of importing the binary
data into the email in the first place, cut and paste from notepad with
binary files can't be a very good idea. :)
If you are concerned with traffic analysis (counting emails and seeing
where they are going), check out anon remailers. But if you don't care
about people knowing you are communicating but you want to protect the
contents, you can skip the work for this step.
>Are there some ciphers more suited to say image and formated documents
>encryption, whereas others more suited to text...Or is it all bits and
>bits...nothing else to consider?
There are text only ciphers, but as a general rule they are easy to
break, and are rather old. Newer ciphers encrypt anything into binary
data, you could use UUencode to convert it back and forth to ascii within
you program if necessary, but simple binary attachments via email are much
less work.
>Obviously data mapping is important..so with a 32 bit colour image, one
>would want to map down the pixel...so for a 54 bit block cipher that
>would be two pixels...i.e. no sheet mapping across pixels....
I fail to see the point. The cipher has no idea what is being
encrypted, it makes no difference if it is text, a 2 color image, a mp3 or
a truecolor image. You read the bytes in from the file, encrypt them,
output the bytes to another file. The exact data being encrypted is
unimportant, after encryption you shouldn't be able to tell a mp3 from a
file consisting entire of '0' bits. If you are interested in writing your
own implementation of RC4, you can contact me via email for help if you
wish. I found it very instructive, and have done some interesting things
with it. (Like written a header to attach to an encrypted file to decrypt
it at the destination without any other software. :)
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Highdesertman)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Sat, 12 Feb 2000 09:56:22 GMT
Reply-To: [EMAIL PROTECTED]
I'm sure somebody will correct me if I'm wrong, but isn't that one of
the mandates that the NSA is tasked with in the first place? Their
base at fort whatever, don't they monitor communications worldwide in
just about every form they take? Don't they scan such things as cell
phone calls by computer? Or am I just a hopeless paranoid?
cheers,
Mathew
On Sun, 06 Feb 2000 08:05:25 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
>On Tue, 01 Feb 2000 15:25:03 +0000, Johnny Bravo <[EMAIL PROTECTED]> wrote:
>>>My suspicion (admittedly without solid basis) is that the government
>>>probably has people working day and night on the problem, and undoubtedly
>>>has algorithms that CAN break encoded messages in finite time, but that the
>>>time involved is still sufficiently long so as to make the routine intrusion
>>>into every pgp message prohibitively costly.
>>
>> Or more likely they can't, but they don't need to. Is your home TEMPEST
>>shielded? I seriously doubt it. The government can park a van outside
>>your building and read everything on your screen, every keystroke you
>>make. If they thought you were worth the effort, they would do so.
>>
>> That is the bottom line, the vast majority of us aren't worth it. The
>>government doesn't give a damn what is in my email, encrypted or
>>otherwise.
>
>But that's why the cracking of PGP would be so significant...
>
>Yes, you're right in that the government is not going to bother sending
>a truck full of electronics to your street, just so that they can eavesdrop
>on your communications.
>
>No, that doesn't mean that breaking PGP wouldn't be a disaster for
>privacy.
>
>Breaking PGP (or other popular personal encryption) suddenly means that
>they don't *need* to expend a lot of manpower to snoop into your
>privacy. They can just sit there with their existing eavesdropping
>hardware on communication trunk lines, and read EVERYTHING with a
>keyword-triggered computer. That's an entirely different level of
>snooping, one that makes it so easy for them that the attitude is
>bound to be, "why the hell not -- let's just scan it ALL". That would
>*not* be the case if they had to resort to sending a truck out to
>every address in the country...
>
>Yes, if they're really after you in particular, they'll get you.
>
>But the big question is, can they get you without even going after
>you in particular in the first place? *That* is the situation if
>PGP is broken (or whatever privacy method you currently use).
>
>
>--
> "How strangely will the Tools of a Tyrant pervert the
>plain Meaning of Words!"
> --Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
** 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
******************************
