Cryptography-Digest Digest #373, Volume #13 Thu, 21 Dec 00 02:13:01 EST
Contents:
Re: Visual Basic Source Code (Paul Schlyter)
Re: All irreducible polys of degree 32 over GF(2) (Scott Contini)
Re: does CA need the proof of acceptance of key binding ? ([EMAIL PROTECTED])
Re: does CA need the proof of acceptance of key binding ? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic Source Code
Date: 21 Dec 2000 05:59:03 +0100
In article <3a3e475b$0$17730$[EMAIL PROTECTED]>,
Jason Bock <[EMAIL PROTECTED]> wrote:
> Paul Schlyter <[EMAIL PROTECTED]> wrote in message
> news:91jkva$9v7$[EMAIL PROTECTED]...
>> In article <3a3d0b6b$0$90275$[EMAIL PROTECTED]>,
>> Jason Bock <[EMAIL PROTECTED]> wrote:
>>> There are situations where it's needed, and other times it's not.
>>> That's the way I've seen it.
>>
>> There are situations where you THINK it's not needed -- but you don't
>> really KNOW after some years have passed. I've been porting some code
>> myself which obviously weren't written with porting in mind.
>
> Guess we have different career insights. But I did KNOW what the
> timelines were for the projects I was on.
So did I. But did you ever consider what might be beyound the
deadlines of your projects?
>>> There are more pressures in software development that programming
>>> in a "real programming language."
>>
>> Indeed very true -- the pressure to get the software out quickly and
>> as cheaply as possible often make developers overlook these issues.
>> As a result the overall cost over the entire lifetime of the software
>> may go up -- but that doesn't bother the initial project which got
>> the first version of the software out the door, since that phase
>> probably got somewhat cheaper.
>
> And if that's what the project lead wants (i.e. the one with the money)
> then that is what happens. I don't necessarily advocate this, but that
> is the bottom line. You can either choose not do what they want and
> not get the project, or you can work with them. I personally opt for
> the latter. I have my views on what software development should really
> be like, but I am usually not in the position to fully steer a project.
> So if quicker is the strongest requirement, I will use a language that
> achieves that goal.
Seems like you've got the wrong customers....
You describe the customer as some kind of dictator, who decides
everything and there's absolutely nothing you can do about it.
That's not quite the case: instead it's a situation of negotiation,
where the customer has his requirements and you have your
requirements. If the two of you can find an agreement there will be
a deal, otherwise there won't be a deal. If the customer is only out
to get the job done as cheaply and as quickly as possible, there's of
course little room for negotiation, and then your choices are to
either accept that quick-n-dirty job or to find another customer.
Sometimes (e.g. if you're short on money and you have no other
customers) it may be the best choice to accept that quick-n-dirty job
- at least it has the advantage of ending quite soon. But if you
find yourself doing these quick-n-dirty jobs constantly all the time,
you should perhaps step back awhile and think about whether this
actually is what you want to do, and if not you should change your
situation.
>>> Or, the project is a prototype,
>>
>> Even if the project is a prototype, its code may be useful later in
>> the real implementation -- that is, if it is of good enough quality
>> to be resued at all... If it never makes it into a real
>> implementation, it becomes my case 1. above...
>
> Although I try to code prototypes as best as I can, I always add the
> qualifier that a prototype is just what it is. It may lead to different
> ideas and the original one may be canned altogether. That has nothing
> to do with the effort of the code underneath. I was just on a project
> where I needed to prototype something on a Jornada unit. I bet none
> of that code will ever see the light of day for that project, but I
> learned a lot and I will use that code base sometime in the future.
You see? It's useful to have what'll happen beyond your prototype
project even if that particular prototype never makes it into a product.
Code snippets can wander between projects -- if they are good enough,
that is.
>>> or the project doesn't have the lifetime of years on end,
>>
>> That was my case 2. above....
>>
>>> etc., etc. Some projects don't live 20 years - sorry if you haven't
>>> seen this.
>>
>> I've seen it all too much. I've seen projects which have lived less
>> than 1 year -- nevertheless even the code from such projects could
>> be reused in other, more long-lived, projects, if it's of good enough
>> quality.
>
> It's not just the quality that matters, though. You have to program with
> reuse in mind.
Yes -- however good quality code is more likely to be reusable than
bad quality code.
And being reusable is in itself a quality in a piece of code. A
piece of quick'n'dirty use-once code might be able to skip some error
checks for instance because "that error will never occur in this
system" (which may be correct and then the code works fine, or it may
be wrong, and then you might get a system crash later on -- only time
will tell if you didn't have the time to do the proper analysis of
the situation). But a piece of code intended to be reusable must do
thorough error checks to ensure that it behaves decently also in some
other system which might want to do other things with that piece of
code.
> Again, if the underlying goal is time-to-market, reuse usually falls by
> the wayside.
But what happens once you're on the market? I guess there'll be
demands for new versions. Will you be able to crate them quickly
enough? Depends partially on how well the original version is -- if
every new version requires a rewrite from scratch becaose of the bad
quality of the code in the older verison ... well ....
...but of course that's not your problem if you, by then, is doing
some other job, rushing some other code to be on market in time...
> But this is getting a bit away from the argument of "is VB a
> 'real-programming language'?" (thank god ;) ).
I hope you understood some of my arguments there though.
>>> You can think that. Change happens irregardless of what I want to do
>>> or not. I don't pretend to have such control over the industry as a
>>> whole.
>>
>> Neither do I -- thus we both agree changes will happen. Now, since
>> one knows changes will happen, why not try to plan for it a little?
>> Of course we won't know exactly what the changes will be,
>> nevertheless there are some things one can do. For instance try to
>> write portable code as much as possible, since portable code is more
>> likely to survive the next paradigm shift than non-portable code.
>
> In that case, one may argue you write it all in Java. Or some other
> language that purports cross-platform use. Problem is, there's SO much
> code written in other languages in other systems that you end up with a
> hard choice. Do you decide to rewrite it all in the current warm-n-fuzzy
> language of the day, or do you try and interop? That's where I think
> we'll eventually end up. It's simply too difficult to get everyone to
> speak the same language and get everyone to use the same OS. You're
> always going to need to interop.
There will of course not be one single language which everyone uses,
and Java is really too young for us to be able to judge how popular
it'll be in 5 or 10 years. However some languages are more portable
than others, and one can at least try to avoid the less portable
languages.
> Of course I recommend writing portable code when I can. Again, though,
> the requirements of a project may not be geared towards such an endeavor.
True. But again, you might then be on the wrong project.
>> I think the only difference between us here is that you're
>> advocating short-term planning while I am advocating somewhat
>> more long-term planning, which initially may be somewhat more
>> expensive but which will pay itself back in the long run.
>
> Depends on the requirements ;).
It also depends on what kinds of jobs you're willing to accept... :-)
>>> Other industries are different. People buying a house won't tolerate
>>> having their house broken down in three years. The computing industry
>>> simply hasn't fought back enough to force stability. But then again, I
>>> don't see that happening for a long time. The industry allows you to
>>> change things at a very rapid rate, much faster than building a house.
>>>
>>> Of course, building software does have a lot of analogies to building a
>>> house. But I just don't see things slowing down for a while. I can
>>> either fight to stay on one OS using one language for the rest of my life,
>>
>> If you do, you'll have to do it as a hobby towards the end of your
>> life, when the commercial lifetime of that OS has ended.
>
> Well, I wouldn't do this. As I stated, things change too much. I really
> don't program much in VB anymore, simply because I don't see a lot of future
> with it in MS's .NET world (I personally use C#).
C# is another non-standard language invented by Microsoft. MS bough
over Anders Hejlsberg (author of Turbo Pascal) from Borland to design
C# for Microsoft. I bet Microsoft has regretted many times that they
once said "No" to Anders Hejlsberg when he asked them if they wanted
to sell his compiler, which later got marketed by Borland as Turbo
Pascal. Turbo Pascal too was non-standard but it created a de-facto
standard by becoming the most popular Pascal compiler. Initially it
was also somewhat cross-platform, being available both for MS-DOS,
CP/M-80 and CP/M-86.
Which probably highlights another difference between you and me: you
seem to want to follow what Microsoft says, while I'm not too eager
to do that. Yes, MS has a big part of the market, but apart from
that MS isn't particularly exciting. Fortunately MS isn't the whole
market, and there are some job opportunities outsides MS market too.
BTW it's really amazing how many C-inspired langauges there are. In
the bookmark list of my web browser I have folders for AWK, C, C--,
C#, C++, EEL, Java, Javascript/Jscript, Perl, Python, Tcl. I could
add one for SALT too, but that C-like language is a little too
special purpose. Objective-C and Embedded C++ ought to have their
own folder though.
>>> or I can decide to watch where things are going and make career changes
>>> based on such observations.
>>
>> "If house built hoses the way programmers build software systems,
>> the next woodpecker which came along would destroy civilisation...."
>
> If house build hoses? Eh??
Sorry, a typo. Should be:
"If house-builders built hoses the way programmers build software
systems, the next woodpecker which came along would destroy
civilisation...."
> I would add this, if (good) developers and programmers were given the time
> to implement systems with reuse in mind, solid test plans, etc., then we
> would be in a better place. But if management is in power and demands the
> new system be done in 2 weeks, there's not much wiggle room.
You can always switch jobs, finding a manager who is more open for
these considerations. If sloppy managers would find it's hard to get
developers working on such consitions, they would become less sloppy
- or vanish from the market.
> But I don't really see what this all has to do with VB being or not being a
> "real programming language." I think it is, just as I think Eiffel, Perl,
> C#, Java, COBOL, Ruby, C, etc., etc., etc., are all real programming
> languages.
I guess we have different definitions of a "real programming language".
> They're all just at a different level of abstraction. VB was designed from
> the start to be an easy way to create Windows programs. It was never designed
> to allow one to create an OS with the tool. But calling it a "toy," or not a
> "real programming language" shows that you haven't used the tool enough.
> I've heard the outcry of "VB is a toy language" so much I just laugh when I
> hear it. It can makes some projects extremely easy and cost-effective. It
> can also make others a living nightmare. Same with other languages in other
> situations.
You're correct that I haven't used VB very much. I really ceased
programming in BASIC in the early 1980'ies, and now I'm somewhat
amazed it's still being used for so-called serious program
development. But perhaps it's the environment more than the language
itself. I did try once or twice though to run some old BASIC
programs on VB and found it far too complex -- it is so much simpler
in GWBASIC.
> Jason
>
> P.S. Personally, if I had the choice I'd have everyone program in Eiffel or
> some derivative thereof. It's one of the cleanest languages I've ever seen.
> But it's used so infrequently that I haven't made it my principle language
> (I need to make money ;) ).
If you had been a programmer back in the early 1960'ies, what
language would you have used? Your choices would have been Algol and
FORTRAN.
In Algol you could have written all sorts of (for that time) elegant
and clean programs, which also would have been portable as long as
you didn't do any I/O (the Algol standard didn't specify any I/O
operations since it considered them to be too "machine dependent").
However you would encounter severe difficulties if you wanted to run
your program, because few Algol compilers were available. Also your
entire program had to be in one single Algol source file, since
separate compilation of subroutines was unavailable in Algol. But
you could of course have built your own pre-processor with #include
directives.
In FORTRAN you would have been forced to unstructured spaghetti code
with lots of GOTO's and similar mess. If you wanted to do some
string processing, you would be forced to mess with storing character
strings in numeric variables since FORTRAN at that time lacked string
variables (and the number of characters which could fit in one
numeric variable would be machine dependent, varying between 4 and
perhaps 10). However, you WOULD be able to run your program on most
of the computers available at that time. And you could build
libraries of often-used subroutines since separate compilation of
sobroutines was available in FORTRAN from a very early stage.
What language do you think you would choose under these circumstances?
--
================================================================
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: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: All irreducible polys of degree 32 over GF(2)
Date: 21 Dec 2000 05:45:56 GMT
In article <3xe06.8114$[EMAIL PROTECTED]>,
Matt Timmermans <[EMAIL PROTECTED]> wrote:
>Note first: I've been on vacation -- sorry to all those I couldn't finish
>arguing with, and thanks to all those who finished my arguments better than
>I would have.
>
>To business, then:
>
>I'm looking for a list of all irreducible polynomials of degree 32 with
>coefficients in GF(2). I've written a program to generate them, but I'd
>rather not have my computer tied up for the week it would take to generate
>them all. Does such a list exist elsewhere?
To add to my previous reply, I just found that the number of
irreducibles of degree 32 over GF(2) is 134215680.
Details:
http://www.theory.csc.uvic.ca/~cos/inf/neck/PolyInfo.html
http://www.research.att.com/cgi-bin/access.cgi/as/njas/sequences/eisA.cgi?Anum=A001037
That's approx 2^27. Each one can be stored in one 4 byte word, so that
makes the list length approx 512 megabytes. There certainly are
tricks to reduce this memory (my guess is that you could make it 1/4th
the size without too much difficulty), but you really are asking for a
long list.
Scott
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: does CA need the proof of acceptance of key binding ?
Date: Thu, 21 Dec 2000 05:56:46 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Timothy M. Metzinger) wrote:
> In article <91qgve$1pg$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>
> > I think besides verification and binding which could be done by the
> >CA or RA even without the acceptance of the applicants for the keys,
we
> >need a proof of acceptance for that assigned key pair, so that are
non-
> >repudiation of the assigned key.
>
> Ummm... The CA doesn't generate the key pair in the scenario I
described. The
> subscriber does. All the CA does is create and publish a certificate
that
> states "this public key was given to me, with proof of identity
binding, in
> accordance with my policies and practices, and therefore I publish
this signed
> certificate".
How the CA verify the subscriber is the one refered in the proof of
identity binding? I think face to face authentication with biometrics
methods is most suitable and secure.
The “proof of identity binding” should have a “proof of acceptance”
of this identity binding from the subsriber.
My key point is that any binding should be approved by the issuing
party and the receiving party.
> The subscriber already possesses his key pairs - he doesn't need to
accept
> them.
The term "accept" in my context is that the person refered in the
proof of identity binding accepts the certificate. The attacker might
misuse my proof of identity binding to apply a certificate, although
the key is generated by the subsriber, but it is not approved by the
party refered in the proof of identity binding.
For example, attacker might use my identity card to apply a phone line,
attacker can provide the particulars, but the assigned phone line is
not accepted by me who is the person refered in the identity card. If
the attacker is willing to put his fingerprint as proof of acceptance,
at least the CA can trace back the attacker and the owner of the
misused identity card is not responsible for the case.
> I'm not sure what value is added to the process by having the
subscriber
> "accept" the key pair(s), since the user generated the key pair(s) to
begin
> with. The subscriber could sign his certificate after the CA
generates and
> signs it as an means of verifying that his certificate accurately
reflects the
> details of his identity, I guess.
How the CA's in real world implement the certificate, they really ask
for signature from the subscriber?
I think the subscriber has use analog signature or analog fingerprint
to sign the certificate from the CA.
Vincent
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: does CA need the proof of acceptance of key binding ?
Date: Thu, 21 Dec 2000 06:02:12 GMT
In article <[EMAIL PROTECTED]>,
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] writes:
> > how's the law interpret this incomplete system?
>
> current debit/atm magstripe card typically has a 4-digit shared-secret
> PIN .... frequently mailed to the person separately by their bank when
> the get a new card. in some of the digital signature laws with respect
> to the retail & financial arena ... it has involved, in case of
> dispute, attempting to change the burden of proof from the
> merchant/bank to the consumer ... focusing on how secure the
> mathematics are ... and somewhat ignoring problems in all the other
> business processes (as far as i know, such provisions have yet to be
> passed).
we know the heart of cryptosystem is the key management, in todays
commercial world, how the key management being handled?
I think key management is not only depending on the hardness of the
mathematics but also the ethics of the parties involves.
> that is ignoring the previously mentioned issue, in the retail
> transaction case, that real identity proofing represents a serious
> invasion of privacy (i.e. any requirement to use a real consumer
> identity certificate in consumer retail transaction)
I think the right of the consumer to protect the abused of their
identity should come first compared to the anonymity.
In Malaysia, many cases of third party uses someone's lost identity
card to get car loan from the finance or to register phone service, I
think these cases could have been avoided by making the proof of
acceptance a compulsary item before binding the user's identity to
something.
vincent
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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
******************************
