Feeds

* Posts by Michael Wojcik

1912 posts • joined 21 Dec 2007

Oz bank in comedy Heartbleed blog FAIL

Michael Wojcik
Bronze badge

Re: Apache & OpenSSL

GnuTLS isn't really much better

Understatement of the year. I've spent a lot more time in the bowels of the OpenSSL sources (an apt metaphor) than in the GnuTLS code, but from what I've seen, GnuTLS is worse.

0
0
Michael Wojcik
Bronze badge

Re: IIS - not affected

Is that because it doesn't need to be, or what?

It's because Microsoft has its own SSL/TLS stack (SChannel, part of SSPI). Microsoft products don't use OpenSSL.

This is a vulnerability in a specific implementation of TLS. It is not a vulnerability in the TLS protocol, or in a cipher suite, which might affect multiple implementations. So it's not like the BEAST, CRIME, Lucky Thirteen, or RC4 attacks of recent memory.

IIS is not affected by Heartbleed for the same reason it wasn't affected by the Apple key-substitution bug or the GnuTLS "we skipped verifying the certificates and don't test our code" bug.

0
0

Google-funded boffins figure out age-busting facial prediction system

Michael Wojcik
Bronze badge

Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte.

0
0

'I was like, yea!' 5-year-old found his Xbox so easy to use, he hacked it

Michael Wojcik
Bronze badge

Re: GoTinder hackers

Plenty of chatbots have managed to fool some people. It's easy when you go for the low-hanging fruit (stupid people motivated by greed, sex, etc). The Turing Test - which is a philosophical proposition, not a proposal for a practical decision procedure - is generally held to a somewhat higher standard, if not rejected outright either as proposition (e.g. by Searle) or practice (e.g. by French).

0
0

Heartbleed exploit, inoculation, both released

Michael Wojcik
Bronze badge

Re: leaving vulnerable information in memory in the first place?

Except in this bug it would have, as the padding beyond the heartbeat request that was returned when the request length was longer would always be zero'd.

I don't believe that's true. First, OpenSSL's malloc wrapper would also have to clear the allocated memory if it took a buffer from its freelist. Second, the packet buffer would always have to be allocated for at least 64KB, regardless of message size; I'm not sure OpenSSL does that in all cases.

In fact, I don't think it ever allocates a packet buffer of that size, at least in 1.0.1c. Look at ssl3_setup_read_buffer in s3_both.c (which also allocates the receive buffer used for TLS). It computes the buffer length using SSL3_RT_MAX_PLAIN_LENGTH, which is ~16BK.

0
0
Michael Wojcik
Bronze badge

They should work with the OpenSSL developers

They are. Rich Salz posted the patch to the openssl-users list, which all the OpenSSL developers follow. Why would you assume otherwise?

2
1

OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts

Michael Wojcik
Bronze badge

Not all OpenSSL 1.0.1x systems are "at risk"

Any machine ... that uses OpenSSL 1.0.1 to 1.0.1f for secure connections is at risk, thanks to the Heartbleed bug.

Not technically correct. OpenSSL can be compiled with Heartbeat or TLS support disabled, and TLS support can be disabled programmatically. It's likely true that the vast majority of systems running OpenSSL 1.0.1[cdef] are at risk, but it's also likely that at least some are not because they were built with a smaller feature set (typically to reduce footprint).

And, of course, since the bug was announced, many people have simply rebuilt OpenSSL 1.0.1x with Heartbeat disabled, so while those systems are still running OpenSSL built from vulnerable source, they are not themselves vulnerable.

This is another reason not to trust those "am I vulnerable?" web sites, by the way. Only a test that actually tries a malformed Heartbeat message is reliable.

1
0
Michael Wojcik
Bronze badge

Re: Dumb design?

Why have a variable length heartbeat payload in the first place?

Read the RFC. It's for Path MTU determination, particularly for DTLS.

0
0
Michael Wojcik
Bronze badge

Re: Where is the buffer overrun?

Show code implementing it the same way, and show how the language of your choice would prevent it.

Have you ever used a language with array bounds checking? Your question appears to be based on complete ignorance.

The Heartbleed bug works like this:

1. Get padding length value from protocol buffer containing peer's message

2. Copy padding-length bytes from protocol buffer containing peer's message to response message buffer

In an environment with proper array management - whether that's a language that does it for the programmer, or an implementation on top of C's bare-bones arrays, which is what a sensible SSL/TLS implementation would use - then either the protocol buffer would have been allocated or resized to the proper size (preferable), or it would be over-allocated to be at least long enough to allow the copy in part 2, and initialized. Those are the only two possibilities for an environment with proper array management.

Then the copy would either fail (former case) or succeed but copy initialized, not reused, data (latter case). That's what would happen with, say, any JVM or .NET language. It's what would happen with any native language that implements array-boundary checks. It's what would happen if OpenSSL employed a trivial abstraction on top of protocol-buffer manipulation, as is commonly done with, for example, Wireshark dissectors (which are also written in C).

Also show how your language would do it if this was the desired implementation i.e some kind of memory sniff/diagnostic tool.

Now that's just dumb. You don't use a deliberate buffer overrun to inspect the contents of your process's own memory. If it's necessary to do that, you use a facility explicitly for that purpose, such as a debugging API or (depending on your needs) the appropriate mechanism for copying data to a byte array, or creating an alias representation.

It's true that there are cases in C where the "trailing array" hack:

struct extensible_data {

...

unsigned char trailer[1]; /* may be allocated larger */

};

arguably makes a deliberate buffer overrun useful, though opinion is divided. But those cases are at best few and far between, and in any event that doesn't apply here.

1
0
Michael Wojcik
Bronze badge

Re: More issues with OpenSSL

OpenSSL is badly written and badly maintained code.

I have a lot of respect for Eric Young and Steve Henson and the rest, but I have to agree. Understanding cryptography and the SSL/TLS protocols and ASN.1 and the rest does not imply good software-development skills. I've spent a lot of time reading and debugging through the OpenSSL sources, and - while I've certainly seen worse - it's not good. Insufficient abstraction, poor choices in identifier names, insufficient comments, and then the infelicitous design decisions that others have noted.

It should be replaced. The trouble is that it's hard to find another library to standardize on, and to be sure that it's correct.

I don't think there's currently a suitable alternative. We've seen dumb bugs in GnuTLS (which has unsuitable license terms for many OpenSSL users anyway), RSA BSAFE (which costs a small fortune), and Apple's implementation in the past few months. Certicom's stack is closed-source and not cheap. Microsoft's is closed-source and only available on Windows. And so on.

Part of the problem is that SSL/TLS is itself a godawful mess, and it employs other godawful messes like X.509 (which means ASN.1, a nasty mess in itself). Part of the problem is that cryptography is, obviously, central to SSL/TLS and hard to get right. And part of the problem is that security in general is very hard to right, and very sensitive to flaws that would be minor in other contexts.

1
0
Michael Wojcik
Bronze badge

Re: no armageddon here thanks

It has NOT been effectively demonstrated in the WILD.

Yes it has. Numerous testers have been able to extract server private keys, for example. Look at heartbleed.com, or for that matter the Cloudfront blog you cited, which has now been updated to indicate they've confirmed the possibility as well.

You *really* need to have a pretty damned good idea of what you're getting back to make any sense of it.

No, you don't. The entire process can be automated. You have the server's public key from its certificate. You just take every byte string of appropriate length from the leaked data and test to see whether it's the corresponding private key. If you want, you can apply some heuristics to cut down the search space (for example, any string that looks like it's all valid ASCII text can probably be skipped; and you can also guess at plausible offsets).

With a GPU farm, or even just a single GPU, you can do a lot of RSA key tests.

1
0
Michael Wojcik
Bronze badge

Re: The problem isn't C

It's the spec.

No, it's not. This issue - self-describing data from the peer - occurs all the time in comms code. Anyone who writes comms code should be aware of it and deal with it as a matter of course. Anyone who's ever written a protocol stack or a Wireshark dissector or anything along those lines should be aware of it. Blaming the specification is endorsing developer laziness.

You cannot assume the data from the peer is well-formed. Period.

And there's no need for a "constructor" of any sort in this case. The code simply needs to validate that the length it's copying won't run past the end of the input, which it could do explicitly before the memcpy or (better) using an abstraction that knows the size of the input buffer and the offset into it. Look at the CVS diffs at openssl.org (I posted the URL in another message, and it's easy to find). It's a trivial change.

2
0
Michael Wojcik
Bronze badge

Re: The real problem is C

Hey, I would love to chuck C as well but Heartbleed could have happened in any language. RFC6520 says return the bytes and the code returns the bytes.

That's a grotesque oversimplification, which is quite an achievement, considering how simple the bug is.

The RFC doesn't require the recipient to honor a malformed Heartbeat request, which is what Heartbleed uses. So citing the RFC is invalid.

And a language that performed array bounds checking would catch the overrun - unless the protocol buffer was over-allocated in the first place, and in that case the hypothetical alternative language would hopefully initialize the buffer (since overrun protection doesn't do that much good unless you also have object-reuse protection).

But, as I've noted in other Reg discussions about Heartbleed, the problem here isn't C. The problem is writing lazy code, with poorly chosen names for identifiers and direct buffer manipulation. A single, very thin layer of indirection for copying between protocol buffers could perform all the necessary range checking.

The problem with OpenSSL isn't C; it's C culture. It's entirely possible to write safe, clean, readable code in C. Most C programmers simply can't be bothered to do so. And of course this is also true of many programmers using many other languages.

2
0

Why won't you DIE? IBM's S/360 and its legacy at 50

Michael Wojcik
Bronze badge

CICS is not an OS

IBM's Customer Information Control System (CICS) is the application server/operating system used to manage transactions on mainframes

Well, one out of three ain't bad, I suppose.

CICS is not an operating system. Neither is it the only IBM mainframe application engine to include a transaction monitor; IMS/TM runs plenty of applications, and I believe there are still some running under TSS as well.

But I'll grant you "application server", for a loose definition of "server".

CICS is a single task that loads and calls application programs in its address space, providing them with various facilities and APIs, including transaction coordination, IPC, terminal I/O, etc. But it runs on top of an underlying OS (zOS, MVS, MVT, VSE, etc).

(IMS/TM is a transaction monitor and message-queuing system that loads and calls application programs as messages become available for them. It's sort of a z Series inetd, except with a transaction monitor built in, and it's often paired with its hierarchical-database sibling IMS/DC.)

1
0
Michael Wojcik
Bronze badge

Re: Mission critical

The clever trick that organisations like Google and Facebook have done is to recognise that certain sorts of activity, such as search, don't actually need to work very reliably which allow for enormous scaling.

Right. This is why we have things like eventually-consistent scaled-out databases for these sorts of workloads, which don't need to worry about skew, stale data, and other inconsistencies for many of their operations, and so can bypass CAP-theoretical limitations by ignoring the problem.

Though ironically this has led to considerable research efforts by Google and the like into improving consistency in massively-distributed, partition-vulnerable systems, giving us technology like Spanner. In that sense we're coming back full circle.

1
0
Michael Wojcik
Bronze badge

Re: UNIVAC 1

http://www.thocp.net/hardware/univac.htm says "3.9 Milliseconds for division". So yes, it looks like the UNIVAC I numbers in the article are in microseconds, not milliseconds.

1
0
Michael Wojcik
Bronze badge

Re: No mention of microcode?

A machine supporting APL natively was considered at one point - I think one was buit in IBM Research - but it was never implemented as a product.

I'm not sure whether you mean "such a machine in the 360 line" or "any such machine". IBM did sell an APL computer - the 5100.

1
0
Michael Wojcik
Bronze badge

Re: Why won't the mainframe die?

How about malware? Both created and prevalent on PCs but not the mainframe.

CHRISTMA EXEC.

Those who forget history &c.

This belief that malware is impossible under the various IBM mainframe OSes is simply ignorance generalized from the paucity of evidence to the contrary. But - as the Reg Commenter Chorus is so fond of reminding us - absence of evidence is not evidence of absence.1

In fact it's not difficult to create malware of various sorts in various IBM mainframe environments. Take CICS - prior to the introduction of Storage Protection in CICS/ESA 3.3, all transactions in a given CICS region shared the same address space and could stomp on one another quite happily. This is rarely a problem because mainframe sysadmins were picky about what programs they'd let be installed on their machines, and those programs were generally written in HLLs that offered amazing features like array bounds checking. But a malicious CICS application, running in a region without SP, can do all sorts of nasty things.

And it's still necessary to get permissions right in mainframe environments. If you're not careful with terminal permissions, a malicious app can issue 3270 Receive Buffer commands and screen-scrape data from privileged apps. And so forth.

Mostly there hasn't been a lot of IBM mainframe malware because it had been too expensive for researchers (of whatever shade of hat) to play with,2 and because there's a correspondingly smaller hacker community to help, and because it's not sexy like, say, breaking a major website.

1More precisely, it's not proof of absence. It is evidence, as any Perfect Bayesian Reasoner could tell you; it's simply weak evidence, and determining its probability with any useful accuracy so you can adjust your model is difficult.

2That situation has changed, for older mainframe OSes, with Hercules.

1
0
Michael Wojcik
Bronze badge

Re: The Naming of Parts

On the contrary...

HTH. HAND.

0
0
Michael Wojcik
Bronze badge

Re: You say "cloud" I say mainframe. You say "browser" I say "dumb terminal."

Which of course means that who runs the mainframe runs you.

Whereas with PCs, you're untouchable?

Honestly, why do people still trot out these sophomoric oversimplifications?

0
0

Amazon stuffs games into Fire TV box: Soz, rivals... WE don't need to make cash on hardware

Michael Wojcik
Bronze badge

Amazon can't manage to recommend books I actually want to buy,

"Anyway, everyone generalizes from a single example. I know I do." (Steven Brust)

what makes them think their recommendations will be any better for films / TV programmes?

Probably the success of their recommendation system at driving additional sales, which they can estimate by measuring conversions (how often people click on recommendations, and how often they then go on to purchase a recommended product). There will be some false positives, but it's possible to estimate those too, with decent accuracy, using other proxies and studies.

But - and prepare to have your mind blown - what does not work for you as an individual customer might work for other customers!

0
0
Michael Wojcik
Bronze badge

Re: It's English, but not as we know it, Jim

That ship has sailed, foundered in a storm at sea, and sunk with all hands lost.

The use of "inform" as a transitive verb applied to activities has a long history, both in the sense of guiding (which seems to be the intended use here) and of providing an essential characteristic ("informs the practice of X"). I notice the Merriam-Webster lists the former usage as "obsolete", but I think they're too hasty there.

Thanks for playing, though.

0
0
Michael Wojcik
Bronze badge

Re: "but all of your video is stored in the Amazon cloud."

If your movies and shows are stored in the cloud, they are tied to Amazon services and devices. Forever.

Which might or might not be a concern, depending on your threat model. I'm not interested in streaming video (beyond what I get from my cable provider's On Demand service, which I use very rarely), but if I was, I wouldn't be at all worried about letting Amazon control my content leases. The risks there are so far down my list they're invisible.

Buffering issues, on the other hand, rain on rich and poor alike. Given the flakiness of my Internet service1, buffering would, in fact, be a much more serious issue for me.

I own a bunch of DVDs (mostly gifts), and most of them have been viewed once or twice, if that. Losing them would not trouble me.

1Also provided by the aforementioned cable company. In their defense, they purchased the previous, bankrupt provider a few years ago, and inherited a greatly oversubscribed, poorly maintained, and generally shoddy infrastructure, and they have been investing steadily in repairs and upgrades. I've had to put in three service calls since they took over, but each time they made substantial fixes.

0
0

Running OpenSSL? Patch now to fix CRITICAL bug

Michael Wojcik
Bronze badge

Re: Reg doesn't seem to get the implications of this bug.

We're running out of SSL/TLS implementations that haven't had an embarrassing flaw documented this year.

And RSA just announced a new one in RSA BSAFE (on Bugtraq; it's CVE-2014-0636, but that CVE is still listed as "reserved" with no info). Apparently this time it's a bug in certificate chain processing that "might incorrectly allow conversations" that should be rejected - in other words, failing unsafe with invalid authenticators in some cases. So equivalent to the GnuTLS bug in severity (worse than the Apple one, not as bad as the OpenSSL one), though currently we don't know anything about the frequency, or how hard it is to exploit.

As always, the devil is in the implementation. And the implementations are all broken.

0
0
Michael Wojcik
Bronze badge

Re: Reg doesn't seem to get the implications of this bug.

I would expect a competent security paper to give us some additional information about when and how the bug was introduced to the SSL source code (go look at a source-code repo somewhere)

Have at it:

http://cvs.openssl.org/chngview?cn=21899

(This change was made before OpenSSL switched to git.) Down near the bottom you'll find the source for tls1_process_heartbeat (there's an equivalent function for DTLS, but really - DTLS? bah!). The bug is obvious in retrospect, IMO, though I think it'd be a lot easier to see if the OpenSSL source base did not continue the very unfortunate tradition of abysmally short and nearly meaningless variable names that infects so much C code. (Watch the variables "pl" and "payload".)

Change submitted by Robin Seggelmann <seggelmann@fh-muenster.de>. I suppose he might be a covert NSA agent, but that seems like a bit of a stretch. This looks like a common-or-garden dumb bug to me.

Indeed, in the annals of dumb SSL/TLS implementation bugs, I think this ranks as less embarrassing than the recent GnuTLS bug, and arguably than the recent Apple bug. I'd even call it less embarrassing than the RSA BSAFE-defaults-to-Dual_EC_DRBG issue, because it appears to be an honest mistake rather than incompetence, which is the kinder interpretation of the RSA fuckup.

We're running out of SSL/TLS implementations that haven't had an embarrassing flaw documented this year. What's left? Microsoft's, Certicom's... I'd be nervous if I were in their shoes. The researchers are on a tear.

0
0
Michael Wojcik
Bronze badge

Re: Isn't it ironic...

I too fail to see anything ironic about it. There are only a handful of official releases in the 1.0.1 stream: 1.0.1c - 1.0.1f, and now 1.0.1g, which was just released on 7 April specifically to address this bug. Releases prior to 1.0.1c don't support TLS Heartbeat, because it's a relatively new TLS option.

Oh, and Jamie Jones: There is nothing wrong with Alanis Morissette's understanding of irony; armchair pedants who think there is clearly don't know what irony is. Irony is one of the four master tropes, and describes any case where expectations are violated, including expectations of the speaker, expectations of the audience, and expectations of convention. Most of Morrisette's examples are of the last category. HTH.

In this case, it's hard to see what expectations might be violated by a list of which OpenSSL releases are vulnerable to this bug, particularly for an observer with any experience in the software industry.

0
1
Michael Wojcik
Bronze badge

Re: Not exactly...

I think what they meant was "it compromises the presumed privacy of private keys". That is, it's a compromise of a feature of the protocol, not necessarily of any given piece of secret data.

As for the probability that a private key will be leaked by Heartbleed: It really depends on a particular binary running on a particular platform, and often on a particular instance of a particular binary running on a particular platform. The amount of data an attacker can get may be less than 64KB, if the overrun hits an unmapped page. If it doesn't, then it depends on whether malloc1 happened to allocate a TLS protocol buffer close enough to an EVP_PKEY structure.

The problem with the probabilistic argument is that there's no way to know if a vulnerable system has ever leaked critical data in the past. You can test your server now, and it might only expose innocuous data, but on the Nth previous run happen to have put that EVP_PKEY right near the overrun buffer.

And if, say, a vulnerable server does leak its private key, it's easy for an attacker to determine that using automated, parallelizable scans. (Basically, just test every byte string of the appropriate length to see if it's the private key corresponding to the public key in the server's certificate. You can use some heuristics to reduce the work required somewhat, too, though in a case like this it's just as easy to throw more hardware at it; you can do a lot of RSA key checks with a GPU farm.)

So the available threat models basically boil down to "assume my private key has been compromised" and "assume my private key hasn't been compromised", if you're running an Internet-facing vulnerable server. There's just no good way to narrow it down more than that, unless you keep extremely detailed logs.

1Assuming you haven't replaced your system's C implementation's malloc as the allocator for OpenSSL.

0
0

US Supreme Court declines to hear NSA mass phone-slurp case

Michael Wojcik
Bronze badge

Re: 'Nuff said

The judges have discretionary powers that are wide ranging,

Yes, because an independent judiciary is extremely important, as anyone who pays any attention to political history knows.

not really beneficial to a 'Democracy'

Assuming "Democracy" in scare quotes means something like "republic in which a substantial portion of the government is democratically elected", which is the form of government we tolerate here in the US, then I'd like to see an actual, substantial argument on this thesis, grounded in some understanding of political science.

when the appointments are largely political.

Well, duh. How else would justices be appointed - a lottery? Several of the states have popularly-elected judges, and let me tell you, that has not proven itself to be a better system.That's why there are checks and balances - in this case, specifically the Senate's confirmation privilege, which has been exercised to reject appointees.

The history of SCOTUS shows numerous occasions where justices opined, voted, and ruled against the explicit preferences of the party and President that nominated them to the bench, starting with Marbury v. Madison in 1803.

1
0

In Australia, protesting against Brendan Eich will be a CRIME

Michael Wojcik
Bronze badge

Re: Want democratic freedoms? Put up with democracy. Brendan rocks, actually.

Is anyone actually saying this?

Indeed. ifconfig, can you please cite some Reg comments that claim Eich "had no RIGHT to speak or act as he did"? I don't recall any, off the top of my head, and if there are some, they're certainly in a very small minority.

0
0
Michael Wojcik
Bronze badge

Re: Forbes was also defending him

But not a word about the people taking Eich's right to employment away.

Perhaps because that didn't happen. In this instance, no one infringed on Brenan Eich's rights in any way, at least according to all the publicly available evidence. If you have evidence suggesting otherwise - that he was fired without cause by Mozilla, say, or that someone coerced him into leaving his position by credible threat of violence - feel free to present it.

Hitler would be proud of you.

No, wait, sorry. Per Godwin, you lose. Now kindly fuck off.

0
0
Michael Wojcik
Bronze badge

Re: @FluffyB Background

I think you will find that the term familly, when applied to human beings, is commonly thought of as being 2 parents and 1 or more offspring.

I think you would find that it isn't, if you were capable of 1) reading comprehension and 2) critical thinking. But I suspect those two conditions are not satisfied.

But if you'd like to provide some evidence to support your daring thesis about the common use of the word "family", I'm sure we'd love to laugh at it.

1
0

Apple sued in Texas troll territory for iMovie patent infringement

Michael Wojcik
Bronze badge

Re: Apple-stealing IP? Hard to believe NOT!

"more damaging than most anything"? It's "more damaging" than armed conflict? Than the anti-vaccination movement? Than lack of access to clean water and safe heating and lighting for millions of people around the world? Than unchecked hyperbole?

The USPTO does not make the laws regarding patents.

If only manufacturers can hold patents, then you've forced small inventors out. You've also made it impossible to capitalize patents, which is the main source of collateral for funding innovation outside of large, established companies and scientific grants to universities - and in the latter case, captialization is a major source of recouping research costs and funding further research. Good job!

(Honestly, this topic seems particularly effective at bringing out the dumbest ideas from the Reg readership, regardless of how often people point out how dumb those ideas are.)

0
0

The Great Hash Bakeoff: Infosec bods cook up next-gen crypto

Michael Wojcik
Bronze badge

Re: Having a cracking time

The ideal security system would contain features that would be unknowable to, or unusable by, people to whom the security credentials did not belong.

Which all falls apart because, by necessity, someone has to do the authentication.

Authentication protocols based on zero-knowledge proofs, such as SRP and PAK-RY, satisfy precisely this criterion: no one but the owner of the credentials knows the secret. Authenticating parties only possess an authenticator, which can be used to authenticate, but not impersonate.

Not even the most ideal security system in the world can defeat an insider.

Since the term "insider" has no technical definition, that's an empty claim. You can always apply Descartes' evil-genius thought experiment to show no security system is perfectly secure, because users can never guarantee that their senses or processes of thought have not been compromised.

In any case, "ideal security system" is not a well-defined term. A system is only secure (or not) in the context of a threat model, and then usually only probabilistically and/or in relation to work factors.

0
0
Michael Wojcik
Bronze badge

Re: Storing unencryped passwords or unsalted passwords

Passwords in 2014? Why aren't we using something more secure?

Indeed. Passwords should have gone away in the 1980s. Even moving to passphrases would be a huge improvement.

There are still sensitive-data consumer sites - Charles Schwab's investor/banking site, for example - that not only don't support passphrases, but have ridiculous limits on the passwords they do support. (Schwab's are limited to 8 characters and don't allow most punctuation, let alone non-ASCII. Someone there really needs to be fired. Even if the back end has those limitations, the front end could allow much better passwords and hash them down into something that meets the backend requirements, which would provide much better usability and make it harder to guess passwords.)

0
0

Vint Cerf wanted to make internet secure from the start, but secrecy prevented it

Michael Wojcik
Bronze badge

Re: After reading the Baker/Applebaum/etc. twitter stuff ...

You omit at least two important details:

- Dual_EC_DRBG is a lousy algorithm - poor performance and no known benefits - and that was recognized when it was originally published. That makes publication and use more suspicious.

- FIPS 800-90A includes instructions on picking different points for Dual_EC_DRBG, which would close any back door. RSA refrained from doing so.

We needn't conclude that RSA made Dual_EC_DRBG the default CPRNG for BSAFE due to pressure or incentives from the NSA; but if they didn't, then they're guilty of insufficient technical review and poor security practice. The weaknesses in and suspicions about Dual_EC_DRBG have been well-known for years, and so there's no excuse for making it the default CPRNG, with the default points, in a library. It's either malice or incompetence.

0
0
Michael Wojcik
Bronze badge

Re: Why do we care about Stewart Baker's opinion ?

It's useful for purposes of historical research and the like to know how people like Baker construct justifications for the NSA's actions. Just because we might disagree with Baker's assessment, or even believe it disingenuous, we shouldn't treat it as irrelevant.

(For the record, I disagree with Baker, and I'm agnostic on the disingenuous question. I'm sufficiently cynical that I have no problem believing either alternative - that he sincerely believes the NSA is in the right, or that he's just practicing PR. And I think that's a moderately interesting but not terribly important question.)

1
0

Internet is a TOOL OF SATAN that destroys belief, study claims

Michael Wojcik
Bronze badge

Bravo, Reg commentators!

I'm cheered to see so many of you - Andrew Jones 2, Fan of Mr Obvious, Martin Budden, Denarius, David Walker, Stoneshop, OldDude, The last doughnut, DougS, localzuk - took the time to read the paper and develop thoughtful, informed, trenchant critiques of the methodology and analysis employed by Downey and his team.

Otherwise, we might have missed out on the knee-jerk accusations of mistaking correlation for causation and so forth that Reg commentators feel they must post whenever any study is reported here. No doubt there are still some readers who have never encountered these concepts, and likely the authors of the study never have either.

1
0
Michael Wojcik
Bronze badge

Re: Ahem

Yes, as Downey himself points out in the frickin' article.

1
0
Michael Wojcik
Bronze badge

Re: At last, and out

the damage done to the Church's reputation

To one church's reputation. And according to the article, most of the decline is among Protestant sects.

Surely that must have had some effect on people's respect for religion.

I believe history shows that there are few things that encourage religious fervor more than denouncing another faith. The failings of a single sect do not appear to dissuade followers of other sects; quite the opposite, in fact.

1
0
Michael Wojcik
Bronze badge

Re: Build schools not temples!

"superstition is inversely proportional to . . . knowledge" (though this is likely true)

Overwhelming evidence suggests otherwise. Indeed, I can't think of a of a historical period where a majority of the most-knowledgeable documented figures of the time were not also superstitious.

Knowledge as such does not convey the ability to think critically, much less the motive to do so.

1
0

SPARC and Solaris will live until at least 2019

Michael Wojcik
Bronze badge

Re: The Oracle Walled Garden roadmap

I find it hard to muster any enthusiasm for SPARC these days, but have an upvote for citing some actual figures and doing the arithmetic. These interminable my-CPU-is-bigger arguments on the Reg are usually filled with completely fact-free posturing.

1
0

The gift of Grace: COBOL's odyssey from Vietnam to the Square Mile

Michael Wojcik
Bronze badge

For sufficiently small values of "wide"

what is widely regarded as the worst mistake in computing history

By whom, Dominic? COBOL was only one of the languages pilloried by Dijkstra in "Truths" - not a thoughtful or useful piece in any case, however wildly overrated in some quarters. Sure, there's plenty of grumbling about COBOL, primarily among people who haven't used a modern variant. But substantial critiques are few and far between, and I'd like to see the evidence for this "widely regarded" rubbish.

As Chris points out, the verbosity of COBOL was specifically to make it readable, and for some programs writable, by non-programmers, so that domain experts - chiefly lawyers and accountants - could validate the business logic. That's an admirable goal that wasn't really taken up again until Knuth's Literate Programming twenty years later (and Knuth's scheme suffers from abysmal source syntax, in typical Knuthian fashion, though the underlying idea is good).

Really, if you can't write an application in COBOL - particularly using modern simplified syntax - in essentially the same amount of time that you can write it in, say, C++, you don't understand at least one of those languages.

(I work for Micro Focus, but I write code professionally in C, C++, procedural COBOL, OO COBOL, and a smattering of other languages; and academically in a couple dozen more. And programming languages is one of my areas of research, and I've presented on COBOL and the economics of source-code readability at academic conferences. So I have a little experience with this topic.)

Also, I don't know where "the two remaining Cobol compiler teams" came from. Did you miss Open COBOL?

7
0

Where the HELL is my ROBOT BUTLER?

Michael Wojcik
Bronze badge

Re: maybe

However, lithium or NiMH, the cost of powering a robot butler using rechargeable cells is still prohibitive.

Robot butler fans: Look for my "fission-powered robot butler" Kickstarter, coming soon!*

*For the beta release, user must supply own fissile materials.

0
0
Michael Wojcik
Bronze badge

Re: It's already here (and has been for years)

How more convenient would it be if the toast and coffee start getting prepared the moment you wake so by the time you get to the kitchen they're fresly ready?

I could do that now. The coffeemaker has a timer and putting the toaster on one would be trivial.

I don't because robbing life of all mundane tasks would be a psychological disaster and philosophically abhorrent. And, good lord, aren't the wealthy (by which I mean anyone middle-class and up in the industrialized nations) fucking lazy enough already?

Spend a minute in the morning putting bread in the toaster rather than on more online lumpeninfotainment. That's how you achieve "work/life balance" - by actually living your damn life.

1
1

BEHOLD the HOLY GRAIL of TECH: The REVERSIBLE USB plug

Michael Wojcik
Bronze badge

Re: We have all experienced Schrödinger's USB stick

Erm, all of mine seem to have something to identify 'top'

Yes, in the existing connector design, a patent design flaw that causes an obvious and common usability problem is "corrected" by imposing additional work on the user. That's a grand solution, and I'm glad Intel decided to stop there for 18 years so you could feel superior.

0
0

Google's SWOLLEN WINDBAGS circle PLANET, dispensing INTERWEBS

Michael Wojcik
Bronze badge

Literary loons

I'll see your Coleridge, and raise you Shakespeare. (Though I confess I might like Coleridge's better too. Depends on the occasion, I suppose.)

0
0
Michael Wojcik
Bronze badge

Re: "It did a lap around the world in 22 days,..."

Thought it took 80 days. Have I missed something?

As faithful readers of William Pène du Bois know, the introduction of the balloon cut the old record in half. Google seem to have achieved another order-of-magnitude1 reduction.

1Binary order of magnitude, natch. This is an IT site.

1
0

ACLU launches user-friendly database of every Snowden doc

Michael Wojcik
Bronze badge

It's swell and all...

... of the ACLU to do this, but couldn't they employ one single competent web developer? The page doesn't even render correctly without scripting enabled, and it's rife with CSS and Javascript errors. The layout is fixed and it's a horrible mess for accessibility purposes (not to mention just reading the damn thing).

0
0

Nothing's as SCARY as an overly aggressive SOFTWARE PIMP

Michael Wojcik
Bronze badge

Re: Unbelievable

I am staggered by the vitriol expressed against people who want to nit-pick pointlessly in the comments. This is the Register, and pointless nit-pickery is what we live for. Back to your cave, AC!

1
0
Michael Wojcik
Bronze badge

Re: Why Adaptec bothered with the 16bit and 32bit cards

And it is transparent and sold as many different options, e.g. Capacity on Demand, where you get the greater performance for just a certain time period.

Indeed. I could have sworn I just read an article here on the Reg that opened with some comment about people not understanding the function of demand in a free market.

(Of course, had this not been a Dabbsy article and all for a lark, I'd've complained that the author apparently hasn't learned anything about economics beyond the summary of Adam Smith in the grade-school encyclopedia. But it is, and so I didn't. A narrow escape for all!)

1
0