Cryptography-Digest Digest #288, Volume #11 Thu, 9 Mar 00 15:13:01 EST
Contents:
Re: Best language for encryption?? (John Myre)
Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the house, where
I am living .. it is a lie .. ("Leo Sgouros")
Re: Your Recommended Choice On Std Crypto Parts (Mike Rosing)
Re: sci.crypt Cipher Contest Web Site (Adam Durana)
Re: sci.crypt Cipher Contest Web Site (Adam Durana)
Re: Universal Language ([EMAIL PROTECTED])
Re: CONFERENCE ON NATURALISM -- FINAL NOTICE (Mike Rosing)
Re: Protocol question -- detecting patching of software (Jack Diamond)
Re: Best language for encryption?? (Paul Schlyter)
Re: Passphrase Quality ? (Johnny Bravo)
Re: sci.crypt Cipher Contest Web Site (Mike Rosing)
Re: Concerning UK publishes "impossible" decryption law (Arturo)
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Thu, 09 Mar 2000 11:11:37 -0700
"Douglas A. Gwyn" wrote:
> I did some programming in Pascal; indeed, it *did* get in the way
> of doing perfectly reasonable things. Is that to be commended?
Whether it is commendable or not is beside the point. I like C,
and one may say it is sufficiently strict for reasonable use, but
really, most people understand "strongly typed" to mean something
stricter than C.
I might add that (as usual), a useful concept (here, type checking
strictness) has been degraded into a binary evaluation: strongly
or weakly typed (the latter being, of course, pejorative). It's
silly. I don't think you can say C is "weakly typed", at least
not the current standard, because the compiler will actually
check stuff for you if you let it. Consider, in contrast, things
like Smalltalk and LISP, or even early C.
If you have to choose between "strongly typed" and "weakly typed"
to describe C, then - you are being asked a stupid question.
...
With regard to the original question (see subject), I think that
in fact type-checking makes encryption algorithms harder to write,
in general, because we usually need to convert data values (e.g.,
between text, bit strings, and numbers). Therefore C's usefulness
in this area is partly because it's type-checking is weaker than
some other languages. Another reason is that the C data types are
closer to the native machine, and modern (symmetric) encryption
algorithms are quite often defined in terms of native machine
capabilities (i.e., bit manipulations).
John M.
------------------------------
From: "Leo Sgouros" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.nordic,soc.culture.israel,soc.culture.europe
Subject: Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the
house, where I am living .. it is a lie ..
Date: Thu, 09 Mar 2000 18:13:27 GMT
whats next kookoo?
gonna post the color and texture of your stool?
how about giving us a day by day description of your clothing?
that sounds interesting...
--
choose mind control
www.mkshadows.net
"J" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
>
> "Markku J. Saarelainen" wrote:
>
> > Actually, I have a sign "Be Aware of Dog" on the garage door of the
> > house, where I am living until I take the world's longest love train
> > ride to Vladivostok, Russia.. The sign itself is a lie .. I have no dog
> > . actually it is just the deception .. you see often the security is
> > based on deception.
> >
> > Yours,
> >
> > Markku
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [EMAIL PROTECTED]
>
>
>
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Your Recommended Choice On Std Crypto Parts
Date: Thu, 09 Mar 2000 12:49:38 -0600
Benjamin Gittins wrote:
> I have not done very much reading on ECC, From what I gather they are
> used in Public Key situations, but can you also use them for symetric
> encryption? If so, how does it compare against something like two-fish,
> setup speeds, etc. Setup speeds REALLY are critical in this application
> unfortunatly.
Use ECC for key exchange and authentication. Use Twofish or Rijndel
(sp?)
for symmetric encryption.
> What would you use in ECC land?
There was a proposal in p1363 to use a simple xor from a hash, but it
was dropped later. I'd stick with AES candidates for your criteria.
> I have been reading up, since posting my first message, crypto papers
> found on Mihir Bellare's website.
>
> http://www-cse.ucsd.edu/users/mihir/
>
> In particular one such document, Entity Key Authentication and Key
> Exchange, talks about the need for mathematically proven protocols.
Yeah, the problem is how you interpret the math. But if the academics
pound on it a while and no holes are found in a couple of years, it's
pretty good.
> I am continuing to read it, and several other papers talking about
> similar design constraints, but is there any public implementations
> available of a key exchange protocol that that meets this strict
> criteria?
Yes. I'll say more below.
> I am also reading another document, Key Agreement Protocols, and their
> Security Analasis, by Simon Blake-Wilson, Don Johnson, Alfred Menezes,
> Sep 9,1997, that also talks about this need.
>
> Their attack model for mallory seems to be a little bit more powerfull,
> and I have yet to fully read/comprehend the need for such a yet more
> powerfull adversary in design. ( other than maybe, future proof
> security? need to read it a bit more ;-)
>
> Again, if there is a standard exchange method written that complies to
> this model, i won't say no to it ;-)
The MQV key exchange (M is from Menezes) has a mathematical proof of
security.
It's part of the p1363, so that's a standard. Public domain code has
been
around for a long time.
> The Enemies, <Grin>, I want to be trully pessimistic about them.
> Very powerfull, as per above mentioned models.
>
> My thinking just now is as follows
>
> 1 - Use SHA-1 On all initial handshaking and the first N packets after.
> - Logic being that this is the most 'fragile' point of
> communications, where the need to establish a session secret needs to
> be protected carefully, using full 160 bit hashs.
>
> 2 - Possibly Use md4/md5 using HMAC, after the n packets, as HMAC seems
> to improve security of a hash function by sharing a secret or
> something. I am also still reading up on that formal document for HMac.
> I am aware the underlying hash must have some minimal level of
> expectation for clash detection, but as said, still reading. Again, MD4
> is fast (and not fully broken yet???), and data will not be vulnerable
> to the style of attack conducted on the SSH???
>
> Speed really is critical, and data is not ultra-sensitive.
>
> Again, peoples thoughts?
Once you have key agreement, you had better be secure. If speed is
critical, don't waste time with too many checks. The overhead of key
agreement should include a check, after that assume you're going to
fly. No point in sending anything if things don't check to begin with.
> I was reading the HMAC paper ( not rfc ) and it talks about there
> possibly being an upside to reducing the amount of bits ( by a little )
> in the hash value to thwart attemtps at reverse engineering. It metions
> of course, that it reduces the amount of combinations for a birthday
> attack..
>
> Any recent developments on this, beyond increasing a small chance on
> birthday attacks? Papers, Documents, ??? Please indicate if you have
> read the paper / his reference to other paper.
Not me. A good hash should be reasonably impervious to reverse
engineering.
SHA-1 seems pretty good so far.
> I saw it! It would be interesting to have a less alpha kit, like, a pci
> board with logic on the pcb, with a cable that runs down to a plastic
> cube with the magic radiation box wrapped up in foil, etc. Protecting
> it from true random acts of malicous pet cats ;-)
:-) I doubt I could sell enough, even in kit form. It'd be in a box,
but don't let the dog piss on it!
> Are there cheap 'acceptable' RNG ready to plug into a std pc / mac?
Yes, lots. Do web search on RNG and serial, you should get quite a few
hits.
> In short, I don't want to have intrinsincly weak design, like what
> happenened with SSH v1.x, nor do I want to use 'bad choice'
> components.. Definitly the Key Exchange protocol should be bullet-proof.
Then MQV is something you want to check out. Use it with Twofish and
SHA-1. the hard part is gluing it together securely. Don't be in a
hurry.
> But again, i'm not so concerened about data eventually being recovered
> in 10 years, as it isn't govt secrets, so faster crypto components, as
> opposed to a paranoid 9 pass DES implementation or what have you. ;-)
>
> There will only be one level of security. Version revision if serious
> flaw becomes apparent, n years down track, in the way the components
> are used ;-)
Right, cryptography is not security. It's just the strongest link
in the chain. Make sure the chain is connected at both ends :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Adam Durana <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Thu, 09 Mar 2000 18:47:38 GMT
David,
I think there has to be some sort of limitation on the memory a
canidate can use because limiting the amount of memory you have to work
with creates a challange. If there was not a limit what would stop
someone from subiting a cipher that used 20 32x32 s-boxes, besides the
fact that any PC wouldn't have enough memory or swap space to run it.
It would be a piece of cake to design a cipher that was secure if the
cipher consisted of 1024 rounds. Maybe we could make a requirement
that a cipher only needs X number of rounds to be secure, and maybe the
memory requirement could be 2 megabytes. I think 2 megabytes is more
than enough. Do you?
- Adam
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Adam Durana <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Thu, 09 Mar 2000 18:51:44 GMT
Sorry for being unclear on the subject. I meant that the cipher as a
whole be original, so you could use things such as fiestel networks and
etc. I just did not want someone to submit something like RC5 using 8
subkeys each round. So as long as a canidate is not a total rip off of
another cipher it should be fine.
- Adam
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Universal Language
Date: Thu, 09 Mar 2000 18:52:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Lassi Hippel=E4inen wrote:
> > But isn't Esperanto just like that?
>
> No. Any language where "carpet" has a gender is not rational.
Huh? Esperanto doesn't have grammatical gender. Whatever gave you that
idea? See <http://www.esperanto.net>.
George
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: CONFERENCE ON NATURALISM -- FINAL NOTICE
Date: Thu, 09 Mar 2000 13:10:26 -0600
John Myre wrote:
> An interesting question is, is it logically possible to prove that
> no scientific explanation could exist for something? For example,
> could you do a computation and show, numerically, that life simply
> cannot arise naturally? On the other hand, could we (Goedel-like),
> show that such a proof is impossible, regardless of the state of
> "scientific" knowledge?
A real example is the distribution of matter in the universe. It is
fairly easy to follow the math and we find that the structures we see
are too complex by "natural" processes to be created in the time the
universe appears to have existed. (It's off by about 10^10, which is
a lot, but I'm not done yet :-) Another example is the relaxation time
of free electrons in a gas. Langmuir showed (around 1910 or so) that
the equilibrium was reached about 10^16 times faster than any model
made sense. Nobody yet can explain it either.
We can always say scientific knowledge is incomplete. By Goedel, we
can claim it is consistent. given that basis, you can say a scientific
basis should exist for everything, but you can also prove you might
never know it! That's not the same thing as proving no scientific
explanation
is possible, because we *might* be able to figure things out eventually.
And where's the crypto? Well, we're decoding the universe here folks
:-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Jack Diamond <[EMAIL PROTECTED]>
Subject: Re: Protocol question -- detecting patching of software
Date: Thu, 09 Mar 2000 19:12:02 GMT
I think you've raised two contexts here, one is internal to the client
program being executed and another is between the client and server
where the server interrogates the client for authenticity. But the
question you've raised really has to do with modifications anywhere in
the client program and how to detect when thats been done.
The overall difficulties are that (a) "programs" when they are executed,
because of possible layers of indirect addressing, dont "know" wheere
all of them (it) is on the computer theyre running on, and (b) code that
modifies itself during execution may never physically exist anywhere at
some points in time. Checksums might work sometimes for static code. The
best solution I suggest is to write your client software making
extensive use of self modifying indirect addressing which is state
driven by the server. This requires solid, fundamental programming
expertise and, if done right, cannot be broken by brute force.
Jack
"Edward A. Falk" wrote:
>
> Hi all; here's a puzzler that's been nagging me for a few days:
>
> You have a multi-player game, where the players run a copy of
> the game on their own computer, and play over the net, connected
> to a server.
>
> It's possible to cheat by patching your copy of the game.
>
> Is it possible to design a protocol by which the server could
> challenge the user's software to ensure that it hasn't been
> modified?
>
> I know someone who did this many years ago by having the software
> execute a checksum on itself and verify the results. Theoretically,
> any tampering with the program would ruin the checksum and bust
> the tamperer. Of course, the tamperer could also patch the checksum
> routine. My friend worked around this problem by having eight
> different checksum routines in different parts of the program.
> The idea was that the tamperer wouldn't find all eight checksums
> and would miss at least one, thus getting busted. This is
> security-through-obscurity, however -- not a real solution.
>
> I'm trying to decide if there's a better way to do this. What I've
> got so far is this:
>
> * Program code contains a cryptographically secure checksum algorithm.
>
> * Server issues a challenge that says: Here is an initialization
> vector. Compute your checksum and send the result back to me.
>
> This doesn't work either though, as the tampered program merely
> keeps an untampered copy around and computes the checksum on that.
> Obviously, the checksum will have to include some sort of dynamic
> but known-to-the-server state. If the program is a game, the
> checksum could be computed based on the initialization vector, the
> program code, and the current game state. This still has holes in
> it though.
>
> Any thoughts on this?
>
> --
> -ed falk, [EMAIL PROTECTED] See *********************#*************#*
> http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
> and read 12 Simple Things You Can Do ******!***************************#**
> to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 9 Mar 2000 18:23:48 +0100
In article <8a8arh$1lnu$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> The most buggy software I have come around is designed with the
> new software crap that tries to protect programmers from themselves.
> Sure the new software crap can make a poor programer produce reams
> of prerry crap that looks functional but does not work. And since the
> modern crap takes one so far from the actual machine code and ties
> the hands of good programmers it is far harder to get rid of vaarious
> bugs. The most relable aircraft coding was done in pure assembly
> and not your high level crap which requires larger machines that run
> much faster to even start to approach what was done in aircraft like
> the A6 and A7.
You included a lot of invectives there -- are you getting out of
arguments?
Regarding your statement: "The most relable aircraft coding was done
in pure assembly" -- could you provide some reference which supports
that claim? I would imagine it's been some time since such systems
were coded in pure assembly -- how do we know that all such systems
which have been produced since then are less reliable?
And -- why bother with assembly? Why not code in Machine Language
directly -- as any REAL PROGRAMMER does? <g>
>> So which paradigm to choose depends on why you are programming and
>> for what purpose your programs are to be used (if they will be used
>> at all.. :-).
>
> Or what false mythd one is suckered into believing.
Which would imply that no matter what onme chooses, the choice
is wrong.....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Thu, 09 Mar 2000 13:50:16 -0500
On Thu, 09 Mar 2000 07:09:58 GMT, jungle <[EMAIL PROTECTED]> wrote:
>killing is assumed as the authorities has been defeated ... no much help for
>the killed as the result of the ordeal ...
You are not making much sense, if you have no other choice post in your
native language and I'll work though a dictionary rather than deal with
your pidgin English.
>> They certainly have nothing to lose in trying,
>
>the problem in not in what THEY have to lose, but what you have to lose ...
This is my point. You tell them I don't have the key, they say "You
lie." and torture you. You keep screaming "I destroyed it, I don't have
the key." and they say "You lie." and torture you some more.
The only way to stop the torture is to give them the key, if you don't
have the key, you have a serious problem.
>wrong assumption,
>you can be killed by torture & have your key ...
And if you don't have the key, you can't give it to them to stop the
torture.
>wrong assumption,
>when authorities need to get the key by torture == they need the KEY BUT NOT
>the person killed ...
You are missing some verbs in that sentence, write it so others can read
it and I'll reply.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Thu, 09 Mar 2000 13:24:05 -0600
Douglas A. Gwyn wrote:
>
> Adam Durana wrote:
> > Does anyone think resistance to linear and differential analysis is
> > too much to ask of the intermediate category?
>
> I think you should ask for resistance to cryptanalysis, period.
> For systems where linear and/or differential C/A is applicable,
> lack of resistance to it should count a few negative points in
> the score.
Or go in a more positive direction, give points for correct analysis.
If one entry includes 5 methods of cryptanalysis and a second includes
10, then the second should get more points (assuming they are all done
correctly).
In beginner class, require at least 2 types of analysis, for
intermediate
require 4 and for advanced require 6. Going above and beyond that gives
more points. Lose points if less than the required amount are wrong :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Thu, 09 Mar 2000 19:01:24 GMT
On Thu, 9 Mar 2000 09:40:03 -0000, "Nick" <[EMAIL PROTECTED]> wrote:
>I suspect thatthe success or (I hope) failure of that particular bit of the
>legislation is likely to rest more on human rights/privacy legislation than
>technical questions about whether one was "in possession" of the password.
>My reasons are:
>
>1) In October 2000, the European Convention on Human Rights becomes part of
>UK law, and includes privacy protection (at least to some degree)
>
>2) English legal practice generally allows less room for technical argument
>than US practice. You might be able to argue in a US court that using a
>mechanism to generate and apply a password means you don't actually
>"possess" the password. In the UK, a court would probably say that on any
>reasonable understandingyou "possessed" the password. An interesting case
>would be that where your employer provided a password generating and
>application mechanism, so you personally didn't know your password.
>
Donīt underestimate public and industry pressure. Thatīs what wiped
out all attemts to enforce key-escrow encryption (UK and elsewhere), and
possibly also worked against Franceīs draconian crypto legislation, now
defeated.
------------------------------
** 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
******************************
