Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:links to NIST (Score 1) 134

Follow this simple rule: don't invent your own crypto. And that goes double for protocols. It's hard. I mean, really, really hard to get it right. If you are not an expert, then there are almost certainly known attacks which will undermine the security of your entire system. If you are an expert, there are still probably subtle attacks (but fewer of them which may not be discovered for years).

I understand most standard modern crypto and protocols quite well. I have studied and worked with it long enough to recognise that using tried and tested methods is almost always the right thing to do. I am not an expert, but I am hopefully a reasonable practitioner.

With that disclaimer out of the way, you need to identify what security you are trying to achieve first, before tacking on cryptographic primitives left right and center. You seem to want message confidentiality and message authentication. For confidentiality with message authentication, use standard constructions. Preferably use an authenticated encryption mode, which has the advantage that they can take less message space than the old style encrypt-then-HMAC constructions, and are usually faster than doing either separately. And you typically only need a single key. If you use the encrypt-then-MAC construction, don't use the same key for encryption as you do for MACing.

Does confidentiality extend to the attacker knowing whether he has seen the same encrypted plaintext before? I.e. should the same plaintext always encrypt to a different ciphertext, or are you happy for the same ciphertext to always be produced for the same plaintext? Do you care about replay attacks? What happens if an attacker replays an old message? Message counters or timestamps can help here. What about non-repudiation? Does it matter whether you can prove which side generated the message or not? For payments, this might be important.

This only scratches the surface. Get proper advice to analyse the true security requirements of your protocol, and use standardised constructions in the implementation. Use BLAKE by all means if it fits the security you need to achieve and performance is a primary requirement. But figure out what security you need first.

Comment You're unhappy with success? (Score 1) 276

Maybe I'm not understanding something here. You don't say that saw the strategic need for this project and developed the idea from the ground up. So I'm assuming you were asked to produce some tech specs for an idea which wasn't originally yours. I don't doubt that developing the specs involved a high degree of skill and ingenuity from you.

Now your boss deems your work to be sufficiently successful to allocate serious resources to it. I'm getting that you feel a very strong sense of technical ownership about this project, but I don't understand why you thought you would lead the entire thing. Is your boss behaving differently to the way the rest of this large, hierarchical company functions?

Having said all of that, congratulations on producing something that clearly has a lot of potential! I echo what other posters have said about not going around management. Talk to your boss in a constructive manner and find out where he sees you fitting in this expanded project. You may or may not like what he says, but at least you'll know where you stand, with your currently great technical reputation intact, and possibly an enhanced reputation for softer skills.

Comment Re:What? (Score 1) 480

Thus speaks someone who has clearly never used Latex.

In Latex, you focus on writing the text, with minimal tags for things like chapter and sections headings. You typically do very no to very little explicit formatting. The latex system does the typesetting for you, producing professional output in whatever styles you have defined.

In fact, this was an aspect of it I actually found occasionally frustrating. It would move diagrams and figures to different pages to produce output it thought would be best. Sometimes I really wanted a diagram on the same page as the text which talked about it - but you often don't get that kind of control in Latex. It does the work for you, and generally produces very good results.

Comment Re:most coders are too inexperienced (Score 1) 317

Well, I've spent the majority of my career doing greenfield projects, so I haven't really seen the kind of coding shop you're talking about. I would have (possibly naively) thought that letting really incompetent programmers work on critical systems is more of a management failure rather than the result of better tools.

My personal style uses a lot of refactoring, particularly the names of things in the early stages. I'm not averse to using good tools outside the IDE too, although I generally prefer to integrate them if possible. As far as I'm concerned, if an automatic tool can do something faster and more reliably than I can, then by all means let the tool do it. It frees me up to focus on the more interesting problems. But each to his own...

I do like what you said about frameworks and libraries, particularly "Frameworks are there to use you!" - that made me smile :)

Comment Re:most coders are too inexperienced (Score 2) 317

I have to say, I'm not one of those who think that making programming easier is making programming worse.

I've been programming for over 30 years (first experience being with hex keypads, teletype terminals and batch processing systems back in the 70s!). I love refactoring support, debugging, in-line help, static analysis, code navigation and folding, documentation generation, etc. They make me much, much, more productive. Anyone who thinks using a text editor, command line or punch-cards is superior is welcome to them, but in my opinion they're crazy!

There may be people for whom all this handholding allows them to write poor software, when they couldn't have done it at all without that level of support. It may also be the case that it allows unmotivated developers to plateau in their abilities too early - although if they're that unmotivated I'm not sure how good they would ever have been.

I'm kind of with you on frameworks though, particularly in Java land. I tend to find that frameworks get me 70% of the way with about 30% of the effort. Win! The next 20% takes me 60% of the effort, just breaking even as I struggle to make it do what I need. Wrestling with incomplete documentation, lesser used functionality and mysterious error messages for which a single plaintive post can be found in the blogosphere somewhere, to which there are no replies ;)

I often wish I'd just ignored the entire framework and built the damn thing myself. But maybe I'm not building typical systems, or something. I guess if you're doing bread-and-butter work where lots of other people are doing essentially the same thing, they may work out better.

Comment Re:most coders are too inexperienced (Score 3, Interesting) 317

There seems to be some truth to this, in my own experience. I find the solutions my younger colleagues invent are just too complicated and gnarly. They haven't yet found how to see the underlying simplicity in the problem and solution - and more importantly, they don't even understand that they should be doing that.

Mentoring is very satisfying, particularly when someone has a "got-it" moment, and their code improves forever thereafter. But I find that is rare. Many people I've worked with - even really, really bright people - just aren't interested in seeing a bigger picture. In fact, I'd go further. Most people will never do this - they will just solve the problem immediately in front of them, without any regard for how the whole thing hangs together, or the semantics of their construction, or the future ease of maintenance of their code.

I guess what I'm saying is that I'm not sure it's really about inexperience, or hardness of career. It's the difference between being a journeyman or a master, and very few it seems have a genuine desire of mastery in what they do.

Comment A very good teacher (Score 5, Informative) 56

I haven't read the book, but I studied cryptography under Professor Keith Martin at RHUL. He was never anything but encouraging of my attempts to design cryptographic protocols. On one occasion I was trying to invent a new symmetric key exchange protocol, reducing the trust required in the trusted third party. He gave me some good pointers, but did observe that the protocol required in the assignment was, by definition, supposed to be a *trusted* third party protocol. Nevertheless, he allowed me to work some of the ideas out a bit more. It was a lot of fun (but a terrible protocol!).

Anyway, I must get a copy of this book. It it's anything at all like his teaching it will be money well spent.

Comment Re:I don't understand (Score 1) 867

I'm not sure most people do swap distros much after they've found something that works for them.

When I was switching away from Windows about 10 years ago, I tried out a few: Mandriva, Suse, and Gentoo for a while. They all had good points and bad points. Gentoo was fun seeing the system built all around me to my specification, but all that compiling and fiddling became irritating after a while, and I just wanted something that got out of my way. I found Ubuntu, and I've basically stuck with it ever since. I almost switched away from Ubuntu when they started the whole Unity thing, so I delayed upgraded to later versions - but Unity in 12.04 is actually pretty good. Not perfect, but quite usable.

The thing about switching distros is it's like switching to a new version of Windows. It's still basically the same system underneath, so you're not relearning everything, but there's a bunch of different tools and things have moved around. It takes time and energy, so you don't really do it unless you're really curious, or you become uncomfortable with your current environment.

Comment Re:CS101 (Score 1) 421

Sorry, I still don't buy it. Most of the people I work with are highly skilled at what they do. Their spreadsheets look fine, and they don't seem to be particularly intimidated.

Logic, in the sense of computer science, isn't really the metric to judge their abilities by - I couldn't do what they do. Or at least, not without a lot of training - and that's something I don't have time for, just like they don't have time to learn in detail what I do.

I'm also not sure why programmers would want their co-workers to specially empathise with them. It just displays a complete lack of awareness of the complexity and challenge in what everyone else does. I started out wanting to say it was an arrogant attitude, but I don't think it's that - it's just lack of awareness.

Now, having been a complete curmudgeon (sorry), I do think that it's good for everyone to learn a bit about what everyone else does. By all means teach the head of sales about lambda calculus, and expect to learn a bit about pipeline development and revenue management strategies. Win-win, as they say :)

Comment Re:CS101 (Score 1) 421

I really don't think it's necessary for everyone in a tech company to understand computers in that way.

I work for a small software company. Our head of sales is an awesome guy, really switched on, understands the products, the market, people, what they want, sales process improvements - the works. I can't see how his ability to do his job would be enhanced by learning computer science, unless he was particularly interested in it anyway.

Comment Re:I propose... (Score 1) 526

Thanks for your interesting replies. It's not an area I know much about.

I had not considered the requirement to ensure that a patient is actually taking the medicine. I suppose you could indirect it a step further, with people who provide assurance whether a pill is taken (or not), but who have no direct contact with the researchers. Of course, they may still introduce bias into the experiment. I suppose you could use a machine which automatically monitors whether the medicine is taken or not somehow, whose results are not known until the end of the experiment.

I have no doubt that such experiments would not pass ethical muster, or would be against the law in some countries. Still, these protocols were designed to reliably test for effects in active compounds. I still wonder how (setting aside ethical or legal constraints) you could construct reasonably reliable trials which test for clinical effects in placebos.

Comment Re:I propose... (Score 1) 526

I mean the second - giving a control group nothing. The first point is well made. In fact, I read somewhere that no doctor or drug ever healed anybody - ultimately it is always the body which heals itself; active drugs only give it a fighting chance to perform its own healing (e.g. by destroying pathogens, or promoting a response to it, or something).

But returning to the second point, I agree you couldn't have double-blind trials as the patient would know whether they got nothing or not. You could still have a blind trial where the researchers did not know who was in the control group or not for the duration of the experiment.

In terms of ethics, if the goal of the trial is to determine whether a placebo has a clinical effect or not, then you are effectively testing a potentially workable treatment (the placebo, even though not pharcologically active) against something known to have no direct effect itself (nothing). So you can still tell patients that there is a 50% chance of getting a treatment that may have a positive effect (but not containing an active ingredient). The other 50% seem to have no hope at all, and they would know it (so you may even invoke the nocebo effect).

It does seem problematic. But if you are interested in whether placebos have clinical effect, how else could it be tested?

Comment Re:Hold still (Score 1) 526

It is my understanding that this is still unproven. While they certainly seem to be most effective in treating perceived symtoms or pain, I believe that it is still an open question as to whether they might have any other clinically useful effects.

Can you provide some references to back up your strongly made assertion that they have no other clinical effects?

Slashdot Top Deals

I cannot conceive that anybody will require multiplications at the rate of 40,000 or even 4,000 per hour ... -- F. H. Wales (1936)