Cryptography-Digest Digest #187, Volume #13 Sun, 19 Nov 00 11:13:01 EST
Contents:
Re: Criteria for Simple Substitutions? ("r.e.s.")
Re: Cryptogram Newsletter is off the wall? (M Taylor)
Re: XOR: A Very useful and important utility to have (Tom St Denis)
Re: AES/Rijndael performance on Pentium 4? (Tom St Denis)
Re: Cryptogram Newsletter is off the wall? (Tom St Denis)
Re: Mode of operation to maintain input size with block ciphers? (Tom St Denis)
Re: Mode of operation to maintain input size with block ciphers? (Simon Johnson)
Re: Cryptogram Newsletter is off the wall? (Bruce Schneier)
Re: Cryptogram Newsletter is off the wall? (Bruce Schneier)
Re: XOR: A Very useful and important utility to have (CiPHER)
Re: XOR: A Very useful and important utility to have (Simon Johnson)
Re: Cryptogram Newsletter is off the wall? (Anne & Lynn Wheeler)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Criteria for Simple Substitutions?
Date: Sun, 19 Nov 2000 06:14:09 -0800
"John Savard" wrote ...
|"news.free.fr" wrote, in part:
|
| >An interesting question
| >
| >How can we measure the "strength" of a permutation ?
| >
| >Is there some references in books or web site ?
|
| Well, the S-boxes in DES were supposed to be strong;
| nonlinearity is required, and there is material on
| 'bent functions'.
Ok, Terry Ritter's pages have a bit to say about this;
e.g., http://www.io.com/~ritter/GLOSSARY.HTM
under "S-Box" and "Boolean Function Nonlinearity".
"Boolean Function Nonlinearity" is said to be a
numerical value that measures the nonlinearity of an
"S-box", but both of these terms seem to be described
relative to bitwise operations only.
Is there any understanding soul in this group who
would explain to a newbie how this applies to the
simple alphabetic substitution tables that I listed?
E.g., for the following two S-tables,
abcdef
======
edfbac (1)
cebafd (2)
what are their respective nonlinearity values,
or which is more nonlinear than the other?
--r.e.s.
------------------------------
From: M Taylor <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 15:08:15 +0000
[EMAIL PROTECTED] wrote:
> If the software is "trusted" and "correct" then we can infer from the
> given facts that the software is correct and trusted that what it
> presents us is what we are in fact signing. It is a matter of trust and
> correctness. If we can meet those requirements, then digital signatures
> can be useful.
>
> I think your argument of data formats and seeing bytes are red herrings,
> there is nothing magically about paper-and-ink signatures.
The points I should of been trying to make are:
a) Yes, we have to be careful of assumptions in our models, i.e.
semantic attacks, where the attacker challenges those assumptions.
b) We should not mistakenly conclude that digital signatures are
useless, but instead that they have limitations. These limitations are
not due to the mathematics, but due to the insecure environment they
typically operate within.
c) There is nothing magical about ink based signatures. Paper and ink
signatures are trivial to hack, forge, repute, modify. Within limits,
digital signatures can possibly 'raise the bar' on the cost of attacks.
By making it less likely, or less profitable, we can hopefully risk
manage the fraud. I suspect that in a well designed _system_ digital
signatures can be arguable easier to audit, and perhaps even have a
higher 'quality' of audit than ink based systems.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: Sun, 19 Nov 2000 15:09:43 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> XOR: A Very useful and important utility to have\
Why?
> A few people in this news group said any XOR program is less than
> useless.
No, they said *your* program is useless.
> If a person has available random number files, an XOR program gives
> you the capability to XOR (encrypt) data.
And just how do they share these super duper random files?
> You really don't need a fancy encryption program. Just random
> numbers in a file and an XOR program.
I think you have a really poor picture of reality. I am not about to
send gigs of data to a friend so we can use some cheap xor program. I
would rather negotiate a shared key via DH or something and use that
instead. It's much simpler, much more practical, etc...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES/Rijndael performance on Pentium 4?
Date: Sun, 19 Nov 2000 15:12:09 GMT
In article <[EMAIL PROTECTED]>,
David Crick <[EMAIL PROTECTED]> wrote:
> I seem to remember talk of (some of) the AES candidates being
> *slower* on the Pentium 4 platform, due to the different (longer)
> times needed to execute certain instructions, etc.
>
> Any idea if Rijndael gets slower or faster on the Pentium 4 platform
> over Pentium II/III?
Who cares? As long as it can handle the megabit/sec range does it
really matter? I think alot of speed arguments (17 cycles per byte vs
23 cycles per byte, etc...) are just plain stupid. On a personal
computer as long as encrypting a 1mbps stream can be done with relative
low loss in performance (i.e you can do other things) I don't think it
matters.
Some examples where 1mbps is perfectly acceptable:
1. File encryption
2. TCP/IP packet encryption which includes various tasks such as chat,
voice, video, https, etc..
3. email encryption, etc..
If you need gbps rates use hardware!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 15:16:50 GMT
In article <AjPR5.855$17.20907@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:8v6rvq$429$[EMAIL PROTECTED]...
> > In article <[EMAIL PROTECTED]>,
> > Bruce Schneier <[EMAIL PROTECTED]> wrote:
> > > On Sat, 18 Nov 2000 14:28:18 GMT, Tom St Denis
<[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >About the signatures. Perhaps Mr Schneier forgot that private
keys
> > are
> > > >often password protected. Unless "Alice" has a poor or easy to
guess
> > > >password it's not so easy to use her signature without her
knowing.
> > > >And like real signatures I could forge it anyways without her
> > knowing.
> > >
> > > We've reached the point where passwords do not provide security
> > > against off-line attacks.
> > >
> > > There is an upper limit of what people can be reasonably expected
to
> > > remember and type in. And over the years, the efficacy of
dictionary
> > > attacks has increased. A few years ago, the two crossed.
> > >
> > > Look at programs like L0phtCrack.
> > >
> > > In any case, passwords are besides the point. If I have a Trojan
on
> > > your computer, I can easily wait until you type your password and
> > > decrypt your private key...and then steal it.
> >
> > Yeah, but there are analogies for any of your counterpoints into the
> > real world. Look at a trojan. I could review tape of a bank when
you
> > sign a cheque. I could then study your signing patterns (the way
you
> > make your letters) and forge your signatures.
> >
> > Like a trojan horse proximity is a problem. Albeit sometimes it
may be
> > easier to install trojans on foolish users (or anyone using outlook)
> > but still for the most part the attack is remote.
>
> This is an underestimate of the problem of trojans. It is quite
difficult to
> guard against this and quite wrong to imply that only foolish users
are
> vulnerable.
>
> A covert virus designed to silently look for, capture and report bank
> account access codes has already been seen in action.
>
> > I think when a digital signature is done properly it can be just as
> > semantically secure as a real signature.
>
> But it is not possible to do a digital signature 'properly' with the
> hardware and software that most people now use.
>
> As Bruce says there is a huge difference between a person signing
something
> and a computer doing this. These are not even remotely similar
activities.
I doubt that. In a lot of respects a hand signature involves variables
in your head that are not known immediately to the attacker. They must
observe and work on a proper forgery.
I do not doubt that perhaps people are a bit stupid about security and
get caught doing stupid things (i.e bad passwords, bad software,
trojan'ed... etc) but when it is done right it can be just as secure.
If I put my signature key on a smartcard and only sign hashes of a
document the only point of attack is really to send an incorrect hash
to the smartcard. The signature is still unbroken just
misrepresentative.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Sun, 19 Nov 2000 15:19:52 GMT
In article <21OR5.3845$[EMAIL PROTECTED]>,
"Benny Nissen" <[EMAIL PROTECTED]> wrote:
> Hi All
>
> Is there a mode of operation where I can maintain the size in all
cases
> (input/output). I know that CFB mode can be used, but with this mode
a new
> IV need to be generated each time to maintain security. I am looking
for a
> way to maintain the size at all times and without the need to make a
new IV
> (a fixed one is OK).
> I have heard about a method called byte stealing, but I do not know
what it
> is all about!
Using a fixed IV for a CFB mode is just a ***STUPID*** thing todo. My
suggestion is to encrypt a binary counter (obviously the initial state
of the counter is the random IV) and just xor as many full and partial
blocks of the encrypted counter as you need. This way you can encrypt
97-bit messages just as easily as 128-bit messages.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Sun, 19 Nov 2000 15:28:59 GMT
In article <21OR5.3845$[EMAIL PROTECTED]>,
"Benny Nissen" <[EMAIL PROTECTED]> wrote:
> Hi All
>
> Is there a mode of operation where I can maintain the size in all
cases
> (input/output). I know that CFB mode can be used, but with this mode
a new
> IV need to be generated each time to maintain security. I am looking
for a
> way to maintain the size at all times and without the need to make a
new IV
> (a fixed one is OK).
> I have heard about a method called byte stealing, but I do not know
what it
> is all about!
>
> Thanks
> Benny
>
>
ECB maintains size, but you probably know this isn't very clever. As
for CBC requiring an IV. Be imagnitive; take the filename, datestamp
and disklocation and turn that into an IV. The physical size of the
file will remain unchanged and the chances of getting a repeated IV are
v. small.
--
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: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 09:37:10 -0600
On Sat, 18 Nov 2000 21:23:10 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>I think when a digital signature is done properly it can be just as
>semantically secure as a real signature.
Lots of things are secure when done properly; this is why so many
security products are completely insecure. The job of the good
security engineer is to imagine how things could not work properly,
and to prepare for those eventualities.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Tel: 408-556-2401
3031 Tisch Way, Suite 100PE, San Jose, CA 95128 Fax: 408-556-0889
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 09:39:24 -0600
For those who do not subscribe to Crypto-Gram, here is my essay:
Why Digital Signatures Are Not Signatures
When first invented in the 1970s, digital signatures made an amazing
promise: better than a handwritten signature -- unforgeable and
uncopyable -- on a document. Today, they are a fundamental component
of business in cyberspace. And numerous laws, state and now federal,
have codified digital signatures into law.
These laws are a mistake. Digital signatures are not signatures, and
they can't fulfill their promise. Understanding why requires
understanding how they work.
The math is complex, but the mechanics are simple. Alice knows a
secret, called a private key. When she wants to "sign" a document (or
a message, or any bucket of bits), she performs a mathematical
calculation using the document and her private key; then she appends
the results of that calculation -- called the "signature" -- to the
document. Anyone can "verify" the signature by performing a different
calculation with the message and Alice's public key, which is publicly
available. If the verification calculation checks out then Alice must
have signed the document, because only she knows her own private key.
Mathematically, it works beautifully. Semantically, it fails
miserably. There's nothing in the description above that constitutes
signing. In fact, calling whatever Alice creates a "digital
signature" was probably the most unfortunate nomenclature mistake in
the history of cryptography.
In law, a signature serves to indicate agreement to, or at least
acknowledgment of, the document signed. When a judge sees a paper
document signed by Alice, he knows that Alice held the document in her
hands, and has reason to believe that Alice read and agreed to the
words on the document. The signature provides evidence of Alice's
intentions. (This is a simplification. With a few exceptions, you
can't take a signed document into court and argue that Alice signed
it. You have to get Alice to testify that she signed it, or bring
handwriting experts in and then it's your word against hers. That's
why notarized signatures are used in many circumstances.)
When the same judge sees a digital signature, he doesn't know anything
about Alice's intentions. He doesn't know if Alice agreed to the
document, or even if she ever saw it.
The problem is that while a digital signature authenticates the
document up to the point of the signing computer, it doesn't
authenticate the link between that computer and Alice. This is a
subtle point. For years, I would explain the mathematics of digital
signatures with sentences like: "The signer computes a digital
signature of message m by computing m^e mod n." This is complete
nonsense. I have digitally signed thousands of electronic documents,
and I have never computed m^e mod n in my entire life. My computer
makes that calculation. I am not signing anything; my computer is.
PGP is a good example. This e-mail security program lets me digitally
sign my messages. The user interface is simple: when I want to sign a
message I select the appropriate menu item, enter my passphrase into a
dialog box, and click "OK." The program decrypts the private key with
the passphrase, and then calculates the digital signature and appends
it to my e-mail. Whether I like it or not, it is a complete article
of faith on my part that PGP calculates a valid digital signature. It
is an article of faith that PGP signs the message I intend it to. It
is an article of faith that PGP doesn't ship a copy of my private key
to someone else, who can then sign whatever he wants in my name.
I don't mean to malign PGP. It's a good program, and if it is working
properly it will indeed sign what I intended to sign. But someone
could easily write a rogue version of the program that displays one
message on the screen and signs another. Someone could write a Back
Orifice plug-in that captures my private key and signs documents
without my consent or knowledge. We've already seen one computer
virus that attempts to steal PGP private keys; nastier variants are
certainly possible.
The mathematics of cryptography, no matter how strong, cannot bridge
the gap between me and my computer. Because the computer is not
trusted, I cannot rely on it to show me what it is doing or do what I
tell it to. Checking the calculation afterwards doesn't help; the
untrusted computer can't be relied upon to check the calculations
properly. It wouldn't help to verify the code, because the untrusted
computer is running the code (and probably doing the verification).
It wouldn't even help to store the digital signature key in a secure
module: the module still has to rely on the untrusted computer for
input and output.
None of this bodes well for digital signatures. Imagine Alice in
court, answering questions about a document she signed. "I never saw
it," she says. "Yes, the mathematics does prove that my private key
signed the document, but I never saw it." And then an expert witness
like myself is called to the stand, who explains to the judge that it
is possible that Alice never saw the document, that programs can be
written to sign documents without Alice's knowledge, and that Alice's
digital signature doesn't really mean anything about Alice's
intentions.
Solving this problem requires a trusted signing computer. If Alice
had a small hand-held computer, with its own screen and keyboard, she
could view documents on that screen and sign them with that keyboard.
As long as the signing computer is trusted, her signatures are
trusted. (But problems remain. Viewing a Microsoft Word document,
for example, generally involves the very software most responsible for
welcoming a virus into the computer.) In this case we're no longer
relying on the mathematics for security, but instead the hardware and
software security of that trusted computer.
This is not to say that digital signatures are useless. There are
many instances where the insecurities discussed here are not relevant,
or where the dollar value of the signatures is small enough not to
warrant worrying about them. There are also instances where
authenticating to the signing computer is good enough, and where no
further authentication is required. And there are instances where
real-world relationships can obviate the legal requirements that
digital signatures have been asked to satisfy.
Digital signatures prove, mathematically, that a secret value known as
the private key was present in a computer at the time Alice's
signature was calculated. It is a small step from that to assume that
Alice entered that key into the computer at the time of signing. But
it is a much larger step to assume that Alice intended a particular
document to be signed. And without a tamperproof computer trusted by
Alice, you can expect "digital signature experts" to show up in court
contesting a lot of digital signatures.
Comments on the new federal digital signature law:
<http://www4.zdnet.com:80/intweek/stories/news/0,4164,2635346,00.html>
(multipage, don't miss the others)
<http://www4.zdnet.com:80/intweek/stories/news/0,4164,2634368,00.html>
<http://www.infoworld.com:80/articles/hn/xml/00/10/02/001002hnesign.xml>
<http://www.pioneerplanet.com/tech/tcv_docs/028992.htm>
A survey of laws in various states and countries:
<http://rechten.kub.nl/simone/DS-LAWSU.HTM>
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Tel: 408-556-2401
3031 Tisch Way, Suite 100PE, San Jose, CA 95128 Fax: 408-556-0889
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: Sun, 19 Nov 2000 15:41:53 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> A few people in this news group said any XOR program is less than
> useless.
No, just yours... like the rest of your 'amazing' programs.
You refuse to open-source them, which can only mean that either (1) You
are running some serious security risk operations in them or (2) You
have little, to no, idea of what you're actually writing and you're
code is an embarrassing mess.
How is _anyone_ expected to trust a closed program from a little NO-ONE
from CA?
Why not trust a easy to use, proven algorithm/program combo such as RSA
and PGP?
That (1) isn't an insanely stupid operation such as XOR or (2) doesn't
require anything but public key exchange.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: Sun, 19 Nov 2000 15:45:04 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> XOR: A Very useful and important utility to have
>
> A few people in this news group said any XOR program is less than
> useless.
>
> If a person has available random number files, an XOR program gives
> you the capability to XOR (encrypt) data.
>
> You really don't need a fancy encryption program. Just random
> numbers in a file and an XOR program.
> Many people say one encryption program is really great or this
> other one is really great, etc.
>
Encryption algorithms are much better than the OTP contruction and
simple Constructions your about to mention. The OTP requires a key-file
equal to the file you want to encrypt. Though the OTP offers perfect
security, this problem makes it useless.
> But many people also question just exactly how secure one or the
> other really is.
>
> If a person has available a few random number generators or can
> generate random numbers from a few encryption programs they can
> combine shuffling several random number files from several of these
> different sources together and create a very secure collection of
> random number files to be used with a simple XOR program to encrypt
> data.
The resultant random file is only as secure as the method of shuffling
or the random number generator used.
> Just name numbering your random number files such as F0001, F0002,
> F0003, etc. and make several of varying lengths to be used to XOR
> files of varying lengths. Have several random number files of 1KB,
> 2KB, 3KB, 5KB, 10KB, 15KB, etc.
>
> Then when you XOR a file make sure its length is no longer than the
> random number file used.
If the random file has a size less than that of the file you wish to
encipher, the construction is totally insecure and can be broken with
only cipher-text.
> Then rename the output file from this XOR process the same name as
> the numbered random number file used in the XOR process.
>
> By reading the name of such a file and knowing that this file should
> be XORed with the random number file you have of the same name, you
> will output the original file when you XOR these two file together.
>
> OAR-L3 is an excellent random number generation program to use, not
> only to generate random numbers, but to combine shuffling random
> number files from various sources using the several shuffling
> routines included with the software package.
>
> OAR-L3 is available for worldwide direct download at:
> http://www.ciphile.com
NO!, if you want any security, use REAL random number generated from
real random events. This method is clunky, and OAR-L3 is probably not
designed for cryptographic needs (never even heard of it :P)
> Go to the Downloads Currently Available web page.
>
> Scroll to the bottom of the page for the blue download link for
> OAR-L3.
>
> You will also find available an XOR Software Utility there for
> direct download as well.
>
> Cheerio!
>
Even if the file is real random and equal in length to the plain-text,
you can only ever use that random file once. After that security is
lost.
Moral of the story: USE AN AES IMPLEMENTATION FOR SECURITY.
--
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.
------------------------------
Subject: Re: Cryptogram Newsletter is off the wall?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 19 Nov 2000 16:02:14 GMT
Simon Johnson <[EMAIL PROTECTED]> writes:
> well i suppose this models reality. If a crook wants to steal the
> contents of a safe. He really has two options:
>
> 1. Break the Safe
> 2. 'Talk' to the guy who owns the safe.
>
> I'd put my bet that breaking the human is easier than the safe!
> The problem with digital security is that there has
> to be human invervention and trust somewhere (and even if there wasn't
> it wouldn't be useful). We can never make things impossible for an
> attacker, just harder. If we have AES vs. XOR then clearly the AES is
> much more likely to be harder to compromise.
there is a much smaller gap between the paper presentation of some
information and a person writing a signature on that piece of paper
... compared to the presentation of some digital information and the
application of a digital signature to that digital information.
two issues ... 1) was the person actually presented what they were
signing and 2) how close a correlation is there between the person's
intent and the application of a signature.
in the digital world ... there is a lot larger gap in case #1 and #2.
for instance, when a person is using a pen to apply a signature to a
paper document ... the probability of that pen wondering off and
signing other pieces of paper at the same time is relatively low.
basically digital signature technology is method of authenticating
digital information ... there has to be a lot of additional
infrastructure wrapped around it to establish correlation between the
digital signature authentication technology and a person's intent.
digital signature likely reduces the probability that there is
counterfeit/fraud once the signature is applied. however, digital
signature infrastructure widesn the gap between what the person sees
and the actual signing operations (opening up new avenues for fraud).
random refs:
http://www.garlic.com/~lynn/aadsmore.htm#schneier
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
** 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
******************************
