Cryptography-Digest Digest #598, Volume #14 Tue, 12 Jun 01 17:13:01 EDT
Contents:
Re: Simple C crypto ("M.S. Bob")
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
([EMAIL PROTECTED])
Re: IV ("Joseph Ashwood")
Re: EXCELLENT NEW WEB BOARD!! CHECK IT OUT :) ("Joseph Ashwood")
Re: Lookup table for DH's prime P? ("Joseph Ashwood")
Re: IV ("Tom St Denis")
Re: differential cryptanalysis with a new twist? ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
(SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
(SCOTT19U.ZIP_GUY)
Re: The 94 cycle 64-bit block cipher :-) ("Tom St Denis")
Re: help non-elephant encryption-URL.. ("Tom St Denis")
Re: Discrete Logarithm ("Tom St Denis")
----------------------------------------------------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Simple C crypto
Date: Tue, 12 Jun 2001 21:28:06 +0100
Dirk Bruere wrote:
>
> Well, that's just not going to happen.
> The requirement is for text comments (for example) to be written to a file
> along with data. We simply don't want people to get into the file to read
> and/or alter the text. We're not talking about professional hackers or the
> NSA, just (say) lab technicians who use the equipment. Detecting alteration
> of the text is something else.
>
> So, no freeware solution to such a simple problem?
I think there are several things Dirk Bruere may want to consider, and
sci.crypt readers should pause to reflect on this "application
programmer" request for a cheap and cheerful "security feature" as if it
was yet another checkbox on the side of a box of software. To clarify, I
mean no disrespect to Dirk, I think his request is some what reasonable,
though strange to cryptology types, and is an accurate reflection of how
a lot of commercial software is written.
Historical the two most common failures seem to be underestimating the
opponent, the most common folly in historic military failures, and
attempting to solve the wrong problem. Underestimating to opponent and
its corollary of a newly proposed cipher being the "unbreakable cipher"
(not Shannon's perfect secrecy) have been played out many times in
history, see _The Codebreakers_ by David Kahn, _The Code Book_ by Simon
Singh or any book about the WW2 effort to break the Enigma.
Nevertheless, people still make the same mistake today. Whether in
regards to the "bored grad student" cryptanalysis attack, or the
"insider" which bypasses any external firewall, people often
underestimate the opponent, or don't know who the opponent is.
A "bored lab tech" that knew a bit of Visual Basic could possibly brute
force a 16-bit key, or cryptanalysis a static XOR 0xAA in their spare
time during a slow 8 hour shift in the lab. Check the Register's website
for an account of a their recent contest to cryptanalysis some
ciphertext for a mere (yet good) paperback book as a prize.
<http://www.theregister.co.uk/content/28/19383.html>
The other common problem is solving, or attempting to solve the wrong
problem. In Dirk's case, he first requested help with encryption using
a simple encryption method, yet later on during clarification it becomes
apparent that there is also message integrity/ alteration/ deletion to
consider as well by the sounds of it. This is often solved with using a
Message Authentication Code (MAC) or a digital signature (e.g. RSA,
DSS). With such a glossed over description of the problems, no idea of
the environment, it is impossible to guess what is reasonable and what
isn't. If the processor of the computer being used is a 1 MHz 8-bit
embedded microprocessor typically used in a smartcard (AES, Twofish,
XTEA) then the suggestions might be very different than if the
environment is a Pentium class x86 CPU (AES, Twofish, Serpent).
Other technical considerations are is a packet-based (UDF) CD-Recorder
practical (or other write-once, non-mutable media)? What about the
append-only file system such as available in FreeBSD? Using that and the
standard Unix file permission (say, non-root users cannot read the file,
even though they could write to it) might be enough to solve your
problems.
The recommended minimal amount of educational investment would be to
read Applied Cryptography by Bruce Schneier and Security Engineering by
Ross Anderson if you want to write a solution that is more likely then
not (i.e. a mere 51% chance or so) of working. Available from at all
fine online book sellers everywhere, and better brick-and-mortar stores.
Schneier has a nifty essay about this, "Why Cryptography Is Harder Than
It Looks" <http://www.counterpane.com/whycrypto.html>, spend 5 minutes
reading it, please.
What is more interesting to me, since I'm not going to benefit from this
produce development as far as I can tell (i.e. either paid, or get the
software), is looking at the experience of general application
programmers and general companies (i.e. not info-security companies)
writing software with "security features". There has been some analysis
of why it doesn't make sense for Microsoft to include a robust and
secure password protection feature in MS-Office since users do call
Microsoft support who want help when they lose their password. These
people get referred to companies like Crak and AccessData who sell
products that help them get back their data.
This developer seems to be looking for a cheap and cheerful toolkit
solution so that he and his manager can check the "security" checkbox on
their product list as features included. Of course this opens questions
of whether poor security is more dangerous since the company (or
employee) is aware that the product is only secure in a very limited
sense. Does this create a potential liability for the company of being
sued if the product gets hacked?
In the real world we don't use vault like doors on our houses because of
various reasons including cost, should we realistically expect
high-grade cryptography in every product? Of course there is little cost
difference to implementing or using TEA, FEAL, crypt(1) versus using
AES/Rijndael, Twofish, and Serpent on a standard desktop PC so it
doesn't make sense to use broken algorithms in a normal environment.
These topics are exploded further in Schneier's Secrets and Lies,
Anderson's Security Engineering, Anderson's new paper "Why Information
Security is Hard - An Economic Perspective"
<http://www.cl.cam.ac.uk/ftp/users/rja14/econ.pdf>, Hal Varian's
"Managing Online Security Risks"
<http://www.nytimes.com/library/financial/columns/060100econ-scene.html>
which is more like a economist's view of information security. Carl
Shapiro and Hal Varian also have a book "Information Rules" that
describes the network economy which is apparently highly recommended
though I haven't had the chance to read it.
I think cryptography is developed a lot like its cousin, space
exploration (NASA et all) which has a history that comes from the
military and that is still apparent in its style (multi-level security,
Trusted Base Computing) rather than the rough-and-tumble world of
"Internet time", constant beta software and Rapid Application
Development typical in application software. Perhaps ubiquitous security
doesn't mean IPSec/ AES/ smartcards/ biometrics/ etc, but requires us to
reconsider how we perceive cryptography in the everyday world, maybe
more like a door lock that works well enough to keep burglary under
control (most burglars don't pick locks) to a manageable degree (risk
management, i.e. insurance).
If Dirk wants to look at some cheap toolkits, consider OpenSSL, whic I
think its license may be acceptable to you (www.openssl.org), check NIST
for an AES reference implementation
<http://csrc.nist.gov/encryption/aes/rijndael/>, Crypto++ and cryptlib
may also be useful, but again check the licenses. If this is tied to a
hardware system you sell, you and your company may consider open
sourcing the software, and just selling hardware and support. You had at
least one indication of a possible offer of help had the software been
open. Several people have conjectured open source software is more
secure due to "more eyeballs", though others have tried to argue the
opinion.
That's my ramblings, I hope it sparks some insight and understanding if
only in the pointers to useful references.
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
From: [EMAIL PROTECTED]
Date: 12 Jun 2001 16:36:41 -0400
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>>
>> You can look at it this way. Factoring is at least NP (and possibly
>> P). So if the bad guy is told, ``Here's Mok's private key,'' he can
>> verify in polynomial time that he actually has the correct key--thanks
>> to your public key. So he can be absolutely sure that he has read your
>> message correctly. That's ``zero information-theoretic security.''
>
> If he gets the private key (or the key in symmetric case),
> then, of course, the security is zero.
No--more than that is true. If an enemy captures (what purports to be)
my OTP, he cannot be positive that it *is* my OTP. It might be a clever
forgery, made by XORing the ciphertext with a false message. There's no
way for him to be sure--he must decide whether he trusts his sources or
not.
> But we are talking about the case where the opponent has the public key.
Right. If the enemy has my public key, he has enough information to
*prove* that a claimed key really *is* my secret key. There is no
possibility of fooling him with a fake key which produces wrong
decrypts.
> If it takes a time for the opponent that is for all practical purpose
> equivalent to infinity (say thirty years) to obtain the private key,
> then one is entirely safe, isn't it?
Yes. The message is ``secure''. But it is not secure in an information-
theoretic sense: it is still possible to be absolutely certain whether
a claimed key is or is not the real key.
Len.
--
Frugal Tip #18:
Get by on your good looks.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: IV
Date: Tue, 12 Jun 2001 13:22:33 -0700
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:9g5rbl$gq3$[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> ha scritto nel messaggio
> news:uPwq$rs8AHA.291@cpmsnbbsa07...
> > Before I make a statement let me try to paraphrase what was said to make
> > sure I understand what you're doing (there may be other problems than
> > security)
>
> Could you elaborate this point?
Depending on how you do things, you can actually end up in a condition where
you cannot decrypt. I no longer consider this a problem of too little
security, instead it appears to be too much.
> My message can be 1 byte long. If you want, you can see the answer of Tim
> Tyler to know what I'm exactly doing in good english.
The repeated IV is a distinct problem. At best each IV should be completely
independent of all the others.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: EXCELLENT NEW WEB BOARD!! CHECK IT OUT :)
Date: Tue, 12 Jun 2001 13:25:25 -0700
I must say. After recieving this message I changed the width of the name
field to not show the last 5 letters of this person's name.
Joe
"CEREBRAL ASSASSIN" <[EMAIL PROTECTED]> wrote in message
news:8ChV6.12007$[EMAIL PROTECTED]...
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Lookup table for DH's prime P?
Date: Tue, 12 Jun 2001 13:37:49 -0700
It's perfectly safe, and in general you don't even need more than 1 prime.
However what you might consider doing is using a fast safe prime finding
algorithm to do some basic sieving, there a re a few of these around. Since
you're worried about speed of selection, what I'd suggest you do is start
the program on startup in the background (as a Daemon, Service, or task tray
entry, or pick something else). Use that process to choose a suitable prime,
and generator, and store those values. Or you could just use the example
from the DSA specification.
Joe
"quequ" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Hi,
> I'm still working on an implementation of DH algorithm and have a new
> little question:
>
> in DH protocol the 1024bit prime P and the generator G are public values,
> it's right?
> In this case can I use a lookup table for P (with 1000-2000 germain
> primes, for example) and a fixed generator G (G = 4)??
> This seems to be a very fast solution, because P take some minutes to
> generate on my machine (K7-500), but is this a safe way to follow?
>
> thanks to all
>
> quequ
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: IV
Date: Tue, 12 Jun 2001 20:51:01 GMT
"Mark Currie" <[EMAIL PROTECTED]> wrote in message
news:3b25cf81$0$[EMAIL PROTECTED]...
> Hi,
>
> Sorry, may have missed a discussion on this, but how does CTR compare with
CBC
> from a security perspective ?
CTR is as secure as the cipher is. Since the plaintext and ciphertext are
not fed into the cipher breaking CTR mode requires predicting the output.
Assuming you don't use more than 2^(n/2) outputs this is as hard as breaking
the cipher to find the outputs with prob 1.
Recall that in a perfect cipher of width n-bits (i.e aes is 128-bits wide)
guessing the L'th output should have a prob of 1/(2^n - 2L).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: differential cryptanalysis with a new twist?
Date: Tue, 12 Jun 2001 20:53:57 GMT
"Mika R S Kojo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> >
> > "Mika R S Kojo" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >
> > > The standard higher-order differential cryptanalysis is slightly
> > > different. It is ultimately about similar sums as your triples, but
> > > based on a bit more elaborate theory. Namely, finding the non-linear
> > > degree of a boolean function (e.g. a block cipher under a fixed
> > > key).
> >
> > Would you mind explaning higher-order differentials. Namely how the
attack
> > works? I have read Knudsen's paper but it's not clear. (Usually it
takes a
> > few reads...)
>
> I don't mind, but my approach to this subject might be even less
> pedagogical than Knudsen's. You may find this a bit difficult but the
> sum (1) below is all you really need.
<snip>
I saved this post to disk. I just got home so I will read over it. Note
that my knowledge of algebraic fields and rings (and polynomial fields and
rings) is a bit loose.
For example, is GF(2^x) a way to denote a field of characteristic two
degree x? Is "x" the extension degree (if that means anything at all?)
[N.B to those that reply, either be kind and say "yes" or "no ... it is ..."
or don't reply at all. I am not interested in a flame war]
Thanks for the reply. I will reply about your post later tonight after I
have re-read it.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: 12 Jun 2001 20:53:57 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B26670B.852B62A5@t-
online.de>:
>
>
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
>> >
>> >But measures should have adquate (intuitionally reasonable)
>> >interpretations, I suppose. If a security measure
>> >says 0 security, then one would 'very naturally' think
>> >that that means no protection at all, isn't it?
>> >
>>
>> But if you don't realize that it has no information
>> theoritic security. Yout less likely to fall into the
>> trap that many programs fall into. Which is to ignore
>> all other possible security features except the hopeful
>> counting on of a hard to exploit work factor. Many
>> encryption pregorams could at least offer some safety
>> if they wished. Such as PGP.
>
>It is my view that such a measure is not an appropriate
>measure for practical use, if it radically contradicts
>indutition. (I would even think that could be an
>indication to re-think about the foundation that lead
>to such a measure.)
>
Thats exactly why you where misled in how to use an OTP
for perfect security. You intuwishtion is not very good.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: 12 Jun 2001 20:51:25 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in
<[EMAIL PROTECTED]>:
>
>Fine. Since we don't have such a one among us, nor do
>we have God (physically) among us, we consequently don't
>need that security at all.
>
Mok just because your not GOD is no reason to give
up on security. And in many finite cases you can get
perfect security. IN other cases there is no reason not
to try to come close. To do anything else is foolish.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: The 94 cycle 64-bit block cipher :-)
Date: Tue, 12 Jun 2001 21:00:34 GMT
"Phil Carmody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Just for fun. (Hey if this works it could be the fastest, simplest
block
> > cipher).
> >
> > I used the quadratic function x(2x + 1) modulo 2^32 as the round
function.
> > It has one nasty differential which is a difference in the high bit goes
to
> > a difference in the high bit with a prob of 1. The rest of the
> > differentials are fairly low bounded by as far as I can tell 2^-16.
(I'm
> > extrapolating from the case of W=8 where the highest is 16/256. Since
we
> > are four times bigger we get (16/256)^4 = 65536/2^32.
> >
> > To avoid this nasty one I used a cyclic rotate left by five bits. Now
the
> > trail has a much lower probability (from the W=8 case it's zero).
> >
> > So we get two rounds for free (first and last). Given 6 rounds we have
a
> > bounded prob of (2^-16)^6 = 2^-96 which means most likely differential
> > analysis won't break the cipher with eight rounds.
> >
> > Of course take heed and remember this is a toy cipher design. It's
still
> > fairly neat that 8 rounds will run in 94 cycles (11.75 cycles per byte).
I
> > want to see about mixing in a PHT with two quadratics.... :-)
>
> Sounds interesting, even if it doesn't have the strength that others
> have.
> You often post your stories here, but I rarely see you post code. As
> someone near the bottom of the learning curve of crypto (I understand
> pure maths, just not how to apply it), maybe you'd like to post your
> code for encrypt and decrypt using the above algorithm, so I can get a
> feel for how it works (how do you decrypt??)
> Your above round function takes 0->0, for reference, which seems less
> than optimal.
I do often post code. See my TC15 stuff for example.
For my new toy ciphers I don't. I can send the ASM source to this new
cipher if you want. But it's just too weak for any serious use.
All of my code is on
http://tomstdenis.home.dhs.org/
Under the "crypto stuff" are my relatively new stuff including my TC15,MDFC
and Noekoen Cryptanalysis papers. On the same page I have the source to the
original and modified TC15 cipher.
Under my "Misc Sources" I have my older TC ciphers. Some of them were
format-destroyed by the hideous GNU Indent program (which is the worst
program in the world). But ones that count are ok. My coolest ciphers are
TC5, TC6 and TC15. TC5 was a recursive Feistel design that I proved was
resilient to first order diff/linear attacks (when I was in Grade 12). TC6
was a decorrelated block cipher that ran at 10 cycles per byte. It wasn't
secure but sure was fast. TC15 was my latest accomplishment. A wide-trail
design that is very fast.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: help non-elephant encryption-URL..
Date: Tue, 12 Jun 2001 21:03:00 GMT
"Jeffrey Williams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> By whose definition? The only relevant text I have at work states that
they
> should be at least one-to-one, which certainly implies that they could be
> one-to-one and onto. The same text states that they must be
computationally
> infeasable to reverse. I always understood that it was that property that
made
> them one-way functions.
A one-way function by definition should only be probablistic in the inverse
direction. Otherwise it is not really one-way.
Like squaring modulo a blum integer is hard the opposite way but isn't
one-way since a solution does exist. And is narrowly defined (i.e there are
four of them)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Discrete Logarithm
Date: Tue, 12 Jun 2001 21:05:53 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote...
> > > JCKW wrote:
> > > > I would like to know how i can solve the integer discrete logarithm
> > > > problem:
> > > Gee, so would I.
> > Not a polite way to deal with a badly phrased question. Tisk tisk.
>
> Hm, I see you're humor impaired.
No I get what you were trying todo. I just think if you are going to spend
the time to reply offer some insight.
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
