 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 07/09/2012 03:46 PM, scott wrote:
>> But don't worry, you're not alone in underestimating the amount of
>> design work that goes into everyday products. Once you've been to a few
>> conferences on design and simulation software you realise that nothing
>> is just designed by trial and error. For example even the part of your
>> dishwasher that contains the salt to soften the water has been carefully
>> studied, designed and simulated to minimise salt use, pressure drop and
>> material costs. Certainly some person didn't just draw it out and say
>> "that'll work, let's test it" and then maybe make a couple of tweaks.
>> You wouldn't survive 5 minutes if your company worked like that.
>
> I can imagine a lot of design work goes into a brand new product. But if
> you're making a dishwasher, you're not making a brand new product.
> You're making a product which is nearly identical to several hundred
> thousand existing products, but with one or two trivial differences.
> Most of the research has already been done. You just need to
> double-check that your new design doesn't contain any unexpected flaws.
Even changing a small mounting bracket requires lots of simulation
(Google finite elements analysis* ) to make sure the bracket will not
break after 3 months of use.
Even if a good deal of the research has been done, a change in
regulations, or market conditions, can force a dish-washing machine
maker to have to review the entire design.
Besides, there's lots of research that has to be redone because it was
initially done by another company and you can't be sued for
reverse-engineering their product, so if both use 1/8th inch mounting
brackets, you need to be able to show a judge that you did do all the
calculations necessary to determine that it was the proper thickness,
ans that you didn't simply copy the other company's bracket.
* lots of math and programming in that field, for someone with an
interest in those. You may not know the first thing about strength of
materials, or vibrations, but the engineers and physicists who do can't
program their way out of a paper bag, so they need programmers and math
is the common languages that these two groups speak.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> Right. And encryption/decryption algoritms sprout from trees?
>>>
>>> From what I've seen, there are, like, three academics globally who
>>> write the vast majority of this stuff. And there are already /way/ more
>>> ciphers in existence than anybody actually wants or needs.
>>
>> Ok. And no one ever needs to implement those algorithms?
>
> Well, that's true. I mean, it's not as if there are already thousands of
> proprietary and open-source libraries that implement both basic
> cryptographic primitives and entire protocols... Oh, wait.
Suuuure. The government, military and finance industries really love
using open-source libraries to encrypt their confidential information.
And private industries really, absolutely, unequivocally love having to
distribute their software for free because theses same open source
libraries have licencing terms that prevent them from being used in
commercial software!
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/09/2012 02:51 PM, Francois Labreque wrote:
>>>>> Right. And encryption/decryption algoritms sprout from trees?
>>>>
>>>> From what I've seen, there are, like, three academics globally who
>>>> write the vast majority of this stuff. And there are already /way/ more
>>>> ciphers in existence than anybody actually wants or needs.
>>>
>>> Ok. And no one ever needs to implement those algorithms?
>>
>> Well, that's true. I mean, it's not as if there are already thousands of
>> proprietary and open-source libraries that implement both basic
>> cryptographic primitives and entire protocols... Oh, wait.
>
> Suuuure. The government, military and finance industries really love
> using open-source libraries to encrypt their confidential information.
>
> And private industries really, absolutely, unequivocally love having to
> distribute their software for free because theses same open source
> libraries have licencing terms that prevent them from being used in
> commercial software!
Perhaps you missed the part where I said there are proprietary libraries
for this as well?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 10/09/2012 02:51 PM, Francois Labreque wrote:
>>>>>> Right. And encryption/decryption algoritms sprout from trees?
>>>>>
>>>>> From what I've seen, there are, like, three academics globally who
>>>>> write the vast majority of this stuff. And there are already /way/
>>>>> more
>>>>> ciphers in existence than anybody actually wants or needs.
>>>>
>>>> Ok. And no one ever needs to implement those algorithms?
>>>
>>> Well, that's true. I mean, it's not as if there are already thousands of
>>> proprietary and open-source libraries that implement both basic
>>> cryptographic primitives and entire protocols... Oh, wait.
>>
>> Suuuure. The government, military and finance industries really love
>> using open-source libraries to encrypt their confidential information.
>>
>> And private industries really, absolutely, unequivocally love having to
>> distribute their software for free because theses same open source
>> libraries have licencing terms that prevent them from being used in
>> commercial software!
>
> Perhaps you missed the part where I said there are proprietary libraries
> for this as well?
No I didn't. I was addressing the open-source part of your comment.
As for proprietary libraries, you do realise that they need maintaining,
being ported to new platforms, etc...
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> As for proprietary libraries, you do realise that they need maintaining,
> being ported to new platforms, etc...
Large, complex applications need maintaining. A small single-function
library that already works correctly? Why would it need any maintenance?
As for porting, most of this stuff seems to be written in ANSI C, and
it's pure algorithmic code. You would /think/ it's fairly portable...
Now, code to drive custom hardware implementations? That might be more
tricky.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As for proprietary libraries, you do realise that they need maintaining,
>> being ported to new platforms, etc...
>
> Large, complex applications need maintaining. A small single-function
> library that already works correctly? Why would it need any maintenance?
> As for porting, most of this stuff seems to be written in ANSI C, and
> it's pure algorithmic code. You would /think/ it's fairly portable...
Still, there's one guy or gal whose job description is to be in charge
of it, just in case. Now, said guy or gal, may be responsible for
hundreds of these single-function libraries, but there still needs to be
someone to wake up at 2am when a someone figures out how to read the
encryption key in memory, or that you thought would be secure since you
ROT-13ed it. Twice.
>
> Now, code to drive custom hardware implementations? That might be more
> tricky.
There you go.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well, that's true. I mean, it's not as if there are already thousands of
> proprietary and open-source libraries that implement both basic
> cryptographic primitives and entire protocols... Oh, wait.
I wonder how many people were involved with defining the standard for eg
the BluRay format? Seems like quite a lot of work heavily based around
preventing people breaking the encryption, and recovering from the
situation if someone does break it. I highly doubt they will just
copy&paste that solution to the next generation format, so surely there
are people actively working on this.
Then not to mention all the people working on writing players for
BluRay, both for standalone hardware and software to run on computers
and games consoles. I imagine you wouldn't be able to do that without a
good understanding of how the algorithms work.
Or maybe you could work for Sony writing rootkits for their audio CDs
:-) Or Sky to encrypt the TV signals from satellites (don't think that
was written once and never changes), or banks or credit card companies,
or ...
It seems like a pretty endless list to me of companies that would
require programmers with a very good understanding of how to select and
implement cryptographic techniques. Hey, even we have two software guys
here implementing these things into RFID tags, and we make printers!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/09/2012 08:38 AM, scott wrote:
>> Well, that's true. I mean, it's not as if there are already thousands of
>> proprietary and open-source libraries that implement both basic
>> cryptographic primitives and entire protocols... Oh, wait.
>
> I wonder how many people were involved with defining the standard for eg
> the BluRay format? Seems like quite a lot of work heavily based around
> preventing people breaking the encryption, and recovering from the
> situation if someone does break it. I highly doubt they will just
> copy&paste that solution to the next generation format, so surely there
> are people actively working on this.
I'm sure the actual cryptographic primitives are well-known
off-the-shelf models. The protocol by which they are combined into a
complete system? Yeah, that's probably band new.
> Or maybe you could work for Sony writing rootkits for their audio CDs
> :-)
You realise that Sony BMG didn't actually /write/ that, right? They just
/bought/ it from some crappy 3rd party company [who presumably has
really good sales staff]. Probably sold it to some marketiod suit who
doesn't understand the first thing about computers, claiming it was a
magic bullet to completely solve all their problems for just $$$/month.
> It seems like a pretty endless list to me of companies that would
> require programmers with a very good understanding of how to select and
> implement cryptographic techniques. Hey, even we have two software guys
> here implementing these things into RFID tags, and we make printers!
Well, maybe. Also seems like they wouldn't need very many of these guys,
and not very often.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm sure the actual cryptographic primitives are well-known
> off-the-shelf models. The protocol by which they are combined into a
> complete system? Yeah, that's probably band new.
That was my point, you seem to be looking very narrow mindedly at jobs,
and deciding which primitive to use and how to implement it into a
complete system in a secure way is not trivial.
> You realise that Sony BMG didn't actually /write/ that, right? They just
> /bought/ it from some crappy 3rd party company [who presumably has
> really good sales staff].
Only if it is a completely off-the-shelf product that can be just used
as-is. I would imagine in most cases the 3rd party would be developing
custom software for someone like Sony, and thus Sony would be quite well
involved with the spec and development, not just at management level.
>> It seems like a pretty endless list to me of companies that would
>> require programmers with a very good understanding of how to select and
>> implement cryptographic techniques. Hey, even we have two software guys
>> here implementing these things into RFID tags, and we make printers!
>
> Well, maybe. Also seems like they wouldn't need very many of these guys,
> and not very often.
If you're looking for a job where you spend 8 hours a day 5 days a week
working on pure crypto algorithms then agreed these are going to be
harder to find than ones where you work on crypto stuff as only a part
of the job. I don't think we would employ anyone solely to do the crypto
work, we need them to do other stuff when necessary (but then we're a
small company where software is a minor part of the product).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6-9-2012 21:05, Orchid Win7 v1 wrote:
>>> The thing is, I can't think of any career that makes use of an ability
>>> to memorise and apply pointless algorithms...
>>
>> Off the top of my head:
>
>> research
>
> Seriously? That's a career? Talk about "vague"...
Not much more than: data-analist, programmer, or even farmer.
FYI when asked what my job is, 'researcher' is my most common reply.
Bio-informatics/bio-statistics would also fit your description.
--
Women are the canaries of science. When they are underrepresented
it is a strong indication that non-scientific factors play a role
and the concentration of incorruptible scientists is also too low
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
