Cryptography-Digest Digest #286, Volume #11 Thu, 9 Mar 00 10:13:01 EST
Contents:
Re: Best language for encryption?? (Paul Schlyter)
Concerning UK publishes "impossible" decryption law (Russell Horn)
Re: OAP-L3 Version 4.2: Updated OverWrite / Delete method (Richard Herring)
Re: Best language for encryption?? (SCOTT19U.ZIP_GUY)
Re: Best language for encryption?? ("ink")
Re: sci.crypt Cipher Contest Web Site (SCOTT19U.ZIP_GUY)
Re: sci.crypt Cipher Contest (SCOTT19U.ZIP_GUY)
Re: Universal Language: was The Voynich manuscript ("Tony T. Warnock")
Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the ("Tony T.
Warnock")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 9 Mar 2000 10:58:55 +0100
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
> > In C, unsigned ints and signed ints can be assigned to one another
> > without a cast -- that would not be the case in a strongly typed
> > language.
> > In C, short ints and long ints can be assigned to one another wihtout
> > a cast -- that would not be the case in a strongly typed language.
>
> I already said that mixed-mode arithmetic is an exception, by which
> I meant to include such things. Because of the value-preserving
> rule, this seldom causes a problem,
You mean like this:
long l = 1000000L;
short s;
..............
s = l;
..............
l = s;
..............
And integer overflows are silent too in C/C++.....
> and it is often a great convenience.
It's a small convenience whenm coding, yes, but may quickly become
a great INconvenience when hunting for bugs,,,,
>> In C, a typedef'ed data type merely becomes a synonym for the base
>> data type, and can be freely assigned from/to it -- that would not be
>> the case in a strongly typed language, where it would become its own
>> distinct data type.
>
> I don't know what it would mean for a C-specific feature "in another
> language". Since typedef (despite its name) does not define a type,
> it has nothing to do with whether strong typing exists. Addition
> and macro definition do not define types, either.
Other languages allow you to specify new types, not merely new names
for existing types. And having a reserved word in C, which suggests
doing something it doesn't do (like "typedef"), is that too a
convenience?
> In C, the way to define a new type is with a struct or union
> declaration. Such types *are* treated strongly; there is no
> automatic mixing allowed among such types (nor between them and
> the built-in types).
...and you can't do any operations on them either, except assignment,
sizeof and and "address-of" (&). In good ol' K&R C you couldn't evne
do struct assignment....
BTW, these types are treated only semi-strongly: you can often override
the typing by using casts.
>> In C, enum's are really int's with some symbolic constants added,
>
> Enums are admittedly a kludge, specified as being selected from
> the available integer types.
>
>> In C, virtually anything can be cast into virtually anything else
>
> No -- only when there are well-defined semantics.
Which there almost are: if a floating-point type is converted to/from
an integer type, some actual conversion is done, otherwise the bit
pattern is just copied. This originate from the K&R C paradigm
"Everything is an int" (including pointers, and excluding only
structs/unions and floating-point types).
> It requires an explicit construct (type cast) to convert among types
> in most cases
:-) ... yes of course. As I said above: "virtually anything can be
cast into virtually anything else". To "cast" something implies using
this explicit type cast construct. But the type cast is merely the
syntax: the semantics behind it is usually just a copying of some
bit pattern (the only exception being when casting a floating-point
type to/from an integer type or another floating-point type).
> (other than the mixed-mode arithmetic already mentioned).
Like:
unsinged int u = -1;
......................
if ( u < 0 ) .....
:-))))))))))))))))))))))))))))
>> that would not be the case in a strongly typed language, where the
>> ability to cast a data type into another data type is restricted
>> on purpose.
>
> When it would be meaningful, what good is served by prohibiting it?
The purpose is to prohibit it when it's *not* menaingful.....
>>> and, alas, a "generic" pointer type void* that
>>> freely interconverts with all object-pointer types,
>
>> I guess that's the last nail in the coffin for your idea of C as a
>> "stronlgy typed language".... such a "feature" would be a cardinal
>> sin in a truly stronlgy typed language.
>
> At least in C, if you use pointer types *and do not explicitly
> invoke the generic pointer type* you still have fairly strong typing.
...which is easily overrided with casts....
>>> but these [escapes from strong typing] occur only if the
>>> programmer chooses to use them.
>
>> I think you should try to do some programming in Ada or Pascal
>
> I did some programming in Pascal; indeed, it *did* get in the way
> of doing perfectly reasonable things. Is that to be commended?
I never said strong typing is to be generally commended. I merely
informed you what strong typing implies. Whether it's to be
commended is a matter of ideology.
The C paradigm of "trust the programmer" worked fine when the C
programmers were quite few and very skilled, but often lead to
disasters when C became a "language of the masses" and many
not-so-trustworthy programmers started using it.
The "strong typing" paradigm of "protect the programmer from himself"
probably works best when teaching new programmers, but it also has
its uses when the software has to be extremely reliable, i.e. where a
program crash isn't merely an annoyance but could actually cost lives
(e.g. control systems for airplanes/airports, or medical equipment).
Yes, it "gets in the way" during the development phase, but it helps
alot during the debugging phase.
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.. :-).
But no matter what your choice here is, the fact remains that C is a
weakly, not strongly, typed language. C++ is somewhat more strongly
typed, but not much: presumably Stroustrup didn't want the typing in
C++ to "get in the way". As a result, there are now numerous
programming guidelines for C++ here and there, where many (most?)
points deal with what features of C++ one should *not* use!
--
================================================================
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: Russell Horn <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Concerning UK publishes "impossible" decryption law
Date: Thu, 9 Mar 2000 11:10:29 +0000
In article <[EMAIL PROTECTED]>, Nick
<[EMAIL PROTECTED]> was heard to say:
>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)
It is already incorporated in Scottish Law. The Scottish Legal System is
different to the English one, not least because Scotland has its own
legislature.
--
Russell Horn
This edition of my .sig has been shortened due to industrial inaction.
Normal service will be resumed as soon as possible.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.privacy
Subject: Re: OAP-L3 Version 4.2: Updated OverWrite / Delete method
Date: 9 Mar 2000 13:32:13 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Tim Tyler ([EMAIL PROTECTED]) wrote:
> In sci.crypt Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> [null-sector wiping]
> : Then will come the screen savers that scrub continuously...
> That might reduce the life-span of the drive somewhat. These things
> do still have moving parts.
There was a long discussion on a similar topic recently in
sci.astro.seti. Informed opinion was that continuous activity
would not significantly affect the drive's life.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best language for encryption??
Date: Thu, 09 Mar 2000 15:00:01 GMT
In article <8a7skv$prr$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Schlyter) wrote:
>In article <[EMAIL PROTECTED]>,
...
>The C paradigm of "trust the programmer" worked fine when the C
>programmers were quite few and very skilled, but often lead to
>disasters when C became a "language of the masses" and many
>not-so-trustworthy programmers started using it.
I see you are fooled into believing one of the great modern myths.
>
>The "strong typing" paradigm of "protect the programmer from himself"
>probably works best when teaching new programmers, but it also has
>its uses when the software has to be extremely reliable, i.e. where a
>program crash isn't merely an annoyance but could actually cost lives
>(e.g. control systems for airplanes/airports, or medical equipment).
>Yes, it "gets in the way" during the development phase, but it helps
>alot during the debugging phase.
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.
>
>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.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Thu, 9 Mar 2000 15:18:42 +0100
SCOTT19U.ZIP_GUY wrote
>In article <8a7skv$prr$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
Schlyter) wrote:
[CUT]
>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.
I'll second that - real programmers write COPY CON: PROGRAM.EXE
;-)))
Kurt
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Thu, 09 Mar 2000 15:15:04 GMT
In article <8a7b5e$q85$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Mr Durana,
>
>The contest sounds like fun. I will be happy to participate.
>
>I would suggest that the criteria for orginality be broad. For
>instance, DES style algorithms should certainly be allowed while an
>obvious DES knock off would be eliminated. Truly unique ciphers are
>almost sure to be insecure.
>
>I have written a cipher as an educational tool for myself. With a good
>key schedule, it should make a good entry.
>
>As for security, all entries should resist all known attacks. Any
>attacks found should count against a cipher. Distant second criteria
>should be speed, memory use, ease of implementation, elegance and
The speed crteria is a joke. Sure if one programs a method poorly
then it will run slowly. But it may will be that among the methods entered
that appear to be secure that the ones which are truely security take longer
to run. If speed is a function I feel it would play directly into the hands of
the NSA and then we would end up with wake shit like the AES methods.
>simplicty. The advanced ciphers should be useable in any mode and as a
>hash function.
I disagree that that have to work in any mode. Again you will just be
playing in the hands of the NSA. I think points should be given if for a one
byte chainge in either the key or input file the whole output file should
change and that the output file should not be longer than the input file.
This goes against the trend in crypto but why should we fall into the trap of
making the cipher easy for the NSA
>
>It will be tough to meet all the criteria. Just look at the AES
>candidates that have been eliminated. The fun is in the trying.
The AES is a phony contest designed to fool stupid people
into using something that the NSA will be able to read. IF you knew
anything about the histroy or the honesty of the agency you would
see why this is true. If your not to old you can see the honesty of
simialr agencies like the FBI which sure as hell don't follow the law.
Look at WACO for a recent example of how honest the FBI is. Yes I
feel I can comment on them after all my mom was an FBI employee
and I know how dishonest the FBI is as all citizens of the world
should know after the WACO incident where the FBI is having to change
the laws it tells every few weeks.
I am taking all suggestions into account.
>>
>> - Adam
>>
>>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: sci.crypt Cipher Contest
Date: Thu, 09 Mar 2000 15:28:16 GMT
In article <qIFx4.478$[EMAIL PROTECTED]>, "Adam Durana"
<[EMAIL PROTECTED]> wrote:
>> Why not specify a 32bit block and 32bit key and judge by clever design and
>> mathematics rather than whether large governments can break it.
>
>If large governments can break it is not the issue. Designing a cipher is
>more than just comming up with an clever and original idea. Part of
>designing a cipher is being given requirements and applying your clever idea
>in a way that meets those requirements. For example you could be asked to
>design a cipher that would work with a specific type of database, and each
>entry in the database is 128bits. Here you would have to design a cipher
>that would be able to encrypt 128bit blocks. So being able to work with and
>fullfil the things that are being asked of the cipher is an important part
>of designing a cipher. By setting block size, key size and etc, its making
>designing the cipher more of a challenge.
By making it more challenging we are following th some path as the AES
which means we are tossing out the main feature which is security. Time and
apace should not count again a method if it adds security and is easy to
understand. It is a fact that good security may take time and space. But if
course you don't wnat to wait several minutes to decupt one one meg file.
>
>> Otherwise it's insane. Lots of people could throw together a semi-secure
>> algorithm if they want to take 20 minutes to encrypt a file or use 40 megs
>of
>> memory, but the algorithms you'll notice in publications fill many design
>> requirements yet still meet their purpose. Theres more to cryptography
>than
>> achieving secure ciphertext.
But it is quite possible that the blessed ones that make it into
publications have followed a carefully guided path that the NSA has
set in motion. And that the secutity is really not there at all. As an
example of you look at my last big money contest. The contest was
such that if any of the weak AES ciphers was used the contest would
have been over in a day. The rason is the AES ciphers due to the design
constrants are inherently weak. Which is just what the NSA wants.
>
>You are right the amount of memory and the speed at which the cipher runs
>should be counted. If you look at my other post in the 'sci.crypt Cipher
>Contest Web site', we where talking about a point system. Each cipher could
>be allowed to use at most 100K of memory and anything over that would cause
>the entry to loose points. We could do the same for the speed of the
>cipher.
Bull shit into days computers there should be no penalty if the method used
needs 20 megs of space. Security into the future such that quantiom compters
would be of little help is what should be a concern. As time goes on computers
are only going to get faster with more memory. Let the phony AES crap handle
the high speed small sized weak methods that the NSA will guide the fools into
using,
>
>Thanks for the suggestions.
>
>- Adam Durana
>
>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Universal Language: was The Voynich manuscript
Date: Thu, 09 Mar 2000 08:00:39 -0700
Reply-To: [EMAIL PROTECTED]
Manuel Pancorbo wrote:
> .
> On the other hand, do you know anybody who learned Spanish as a second language that
>read any piece of Spanish literature? I don't mean "El Quijote", that many spaniards
>didn't read yet :-(, but Federico Garc�a Lorca, Cort�zar, Garc�a M�rquez... in my
>case I know a lot of people who learned (?) English, but I can't certify that any of
>them read Shakespeare, Joyce or Hemmingway in their native language.
Me. I haven't read Quijote yet but some 30 years ago I read a bunch of novels and
plays. "Cronica del Alba" and "El Sombrero de Tres Picos" come to mind as titles but I
can't remember the authors. Also a bunch of French plays including "Cyrano."
I haven't read Hemmingway or Joyce for more than a few pages each but I have read most
of Shakespeare and seen most of his stuff on stage or film.
------------------------------
From: "Tony T. Warnock" <[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
Date: Thu, 09 Mar 2000 08:04:12 -0700
Reply-To: [EMAIL PROTECTED]
Outsider wrote:
>
> If you want a good sign, place a sign that says the following on
> your front and back doors.
>
> ===============================
> Trespassers will be shot.
> Survivors will be shot again.
>
> (picture of gun)
>
> ===============================
I once saw a similar sign that said: "Trespassers will be shot. Survivors
will be held for ransom."
------------------------------
** 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
******************************
