Feeds

back to article Crypto protocols mostly crocked says euro infosec think-tank ENISA

It's past time to plan the abandonment of legacy crypto, warns the European Union Agency for Network and Information Security (ENISA) in a new 96-page study providing recommendations for crypto designers that also says most protocols are hard to install in a secure fashion. The good news, however: behind the huge amount of …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

Two of the Blowfish...

What's wrong with Twofish? Is it perhaps too good, and so was censored out of the analysis?

2
1

Re: Two of the Blowfish...

I wondered why Twofish wasn't mentioned, myself. The report indicates (top of page 25) that Blowfish's 64-bit block size was why it was only recommended for legacy use; because Twofish uses 128-bit block sizes, just like AES, presumably it'd get higher marks. However, while this does seem like an odd oversight, I wouldn't jump to the conclusion that any censorship was involved.

0
0
Silver badge

For extra security

Make sure you use the closed source versions of these that come with that American made operating system.

11
0

AES?

Wasn't that compromised by the NSA?

0
1
Anonymous Coward

Re: AES?

"Wasn't that compromised by the NSA?"

Nah, that was elliptical curve. The constants provided by the NSA are unexplained. The maths for elliptical curve is fine, but the standard implementation is tainted:

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

If those constants create a backdoor, then as soon as the backdoor key is broken (it most likely already is), then all elliptical curve keys are broken.

AES remains secure except for the recommended key size being too short, (also courtesy of NSA lobbying).

4
0
Silver badge

Re: AES?

Nah, that was elliptical curve

Nah, it was Dual_EC_DRBG, which is one specification for one application (a CPRNG) of elliptical-curve cryptography. There's nothing "compromised" about EC in general. And in fact there's nothing fatally wrong with Dual_EC_DRBG, as long as you generate your own Q, and the specification tells you how to do that.

If those constants create a backdoor, then as soon as the backdoor key is broken (it most likely already is), then all elliptical curve keys are broken.

No, the Dual_EC_DRPG alleged (albeit likely) backdoor lets an attacker reconstruct the CPRNG stream, which generally leads to such exposures as recovering the session key. That's generally a key for a symmetric cipher, and not an EC key at all.

Unless you're talking about some other alleged backdoor. I didn't see a reference to EC at all in the Guardian story you cited, though I admit I just searched and skimmed.

1
0

No mention of asymmetric encryption?

It's how you secure symmetric keys, after all...

1
1

Re: No mention of asymmetric encryption?

The report deals with it. In fact it deals with factoring, descrete log and parings as primitives used for pubkey crypto and a list too long to type here of schemes and protocolles based on those.

0
0
Gold badge
Unhappy

Sounds like solid stuff.

Bottom line.

The internet was designed on the basis that everyone was a "good citizen" and would not peek at packets addressed to others, because they did not need to or want to.

We now know that is no longer the case and all links (including the end points) should be considered suspect. The challenge is to make the metadata IE the address and routing, as secure as the content.

I believe the best defense of both individuals and societies freedom and privacy is to properly implement systems that protect everyone's freedom and privacy. We are adults in an adult world..

A bit sadder but a lot wiser about whose interested in spying on you.

3
0
Gold badge

Re: Sounds like solid stuff.

"The challenge is to make the metadata IE the address and routing, as secure as the content."

"As secure as the content" is a pretty tall order. It's fairly easy to arrange that an intermediate router can send packets in the right direction and not have a clue about what they contain. Pulling the same trick on the address label is going to be Hard.

1
0
Silver badge

Re: Sounds like solid stuff.

"Pulling the same trick on the address label is going to be Hard"

But not impossible - although it would be expensive and require you to trust the implementation. You're basically talking about a VPN'd proxy service.

Eg. Source -> VPN -> Internet -> VPN Proxy Termination point/Router <- Internet <- VPN <- Destination

You would need a lot of these proxies dotted around if you want to avoid traffic travelling halfway around the world, and it's still vulnerable if the proxy's are compromised, but then you could put more resources into securing and monitoring it.

Edit: After re-reading this it looks just like a digital drop box of sorts.

1
0
Gold badge
Unhappy

Re: Sounds like solid stuff.

""As secure as the content" is a pretty tall order. "

That's why I described it as "challenging"

1
0
FAIL

"Crypto designers should stick to SHA-2, SHA-3 or Whirlpool for their hashes, and where there's a choice, opt for longer outputs. SHA-1, SHA-2 and RIPEMD-160 are only suitable for legacy applications. "

SHA-2... So which is it? Stick with it or sutible only for legacy applications?

4
0

SHA-2

It depends on the size. From the report: "we denote SHA-224 as in the legacy only division of our analysis", and "for near term use we recommend SHA-256 and for long term use SHA-512."

3
0
Bronze badge

SHA-2... So which is it? Stick with it or sutible only for legacy applications?

SHA-2 is a family of hash functions. See Michael's post above.

0
0
Bronze badge

Cross platform security kit

This is what I want: someone clever to spend his/her days creating guidelines and a spec for a security API that then gets open source reference implementations in various languages, so I can just keep that library up to date and it'll set out for me recommended ways of doing everything. E.g. this is our recommended password spec for a really secure site (e.g. banking), for a fairly secure site (e.g. Facebook) and for a random site (e.g. comment on a forum I'll probably never visit again).

Case in point: Halifax's password requirements are as follows:

Minimum 6 characters (should probably be 8).

Case-insensitive (WHAT?)

No special characters allowed (WHAT?)

How that passes any modern standards is beyond me. Except it's not; I've been in the sorts of meetings where this gets set out. It's all people who know nothing about security, and they just say, "Well XYZ website does it like this, let's copy them."

If they just had something that gave them code to validate password strength (presumably set to the most secure setting, since they're a bank) and told them what the right thing to do is, we shift the problem out of a room full of people ignorant of security, and onto a standard.

And I know, half of this is framework, half is training etc etc, can't all be solved with an API. It's just annoying that things like security questions always come up, and every two years or so there's a comparison on Stack Overflow of the ten best PHP authentication frameworks, when security hasn't changed that much and we just need one standard. Until we standardise this layer, we never get to innovate in higher ones.

2
0
Silver badge

Re: Cross platform security kit

It's possible that Halifax have made a sensible choice (though your explanation is perfectly possible too). Security is always a trade-off. Halifax could force all their customers to have passwords such as @4&KA|xCf but they'd need to employ twice as many people on their helpdesk resetting passwords (probably dependent on the answers to 'secret' questions such as mother's maiden name or school attended). If the only interface to their system is through the web and they can block your account after 3 unsuccessful attempts, maybe 6 alphanumeric characters is sufficient (at least, it's a different problem than choosing root passwords on a *nix system).

1
0
Silver badge

Re: Cross platform security kit

They do also require 3 random characters from an additional password input via pull down menus

I

0
0

Re: Cross platform password standards

Those password rules are just copying what people have done before (with a few variations to annoy the victims).

For online systems such rules are a defence against the poor implementation of an authentication server, which allows hackers to steal the entire database. Which just should not be allowed, we've had much stronger technology for years.

What should be required is

a) strong hardware-based protection of the database - think HSMs or single-function appliances in a monitored datacentre that provides no admin or physical access to the database.

b) lockout against brute-force attacks, either 5-stikes and out or exponential backoff.

With those provisions, 4 or 5 digit pins should be adequate for most online functions. Just as is done for credit cards.

0
0
Bronze badge

Re: Cross platform security kit

I think maybe you misunderstand :) I'm not saying they should enforce the use of special characters or mixed-case passwords; I'm saying that they state that their password checks are case-insensitive, and that you aren't allowed special characters in your password.

1
0
Gold badge
Unhappy

Re: Cross platform password standards

"a) strong hardware-based protection of the database - think HSMs or single-function appliances in a monitored datacentre that provides no admin or physical access to the database."

Well Intel seem to have taken this function into the microprocessor itself.

Of course you can't be sure how secure that is because what's on the chip is AFAIK a mystery to

everyone without an electron microscope.

It is about about as hard wired as you can get however.

0
0
Silver badge

Re: Cross platform password standards

What should be required is

a) strong hardware-based protection of the database - think HSMs or single-function appliances in a monitored datacentre that provides no admin or physical access to the database.

b) lockout against brute-force attacks, either 5-stikes and out or exponential backoff.

With those provisions, 4 or 5 digit pins should be adequate for most online functions. Just as is done for credit cards.

That's insufficient. There's a well-known attack against schemes like this which has been seen in the wild; it was documented on BUGTRAQ in the late '90s, if you want to look for it.

Briefly, because the secret space (4- or 5-digit PIN) is so small, the attacker can assume that a given PIN is probably in use by some accounts, if there are many accounts (as there are with a large bank). And in fact it's worse than that, because the use of PINs chosen by users is strongly biased: people use dates, or use the telephone lettering scheme to convert words to digits (which makes some digits more probable, and makes 1 and 0 much less probable).

So you pick a PIN and try it against every valid account number. Because you're probing a different account on each request, there's no opportunity for lockout at the account level. You can avoid lockout based on, say, originating IP address by employing a botnet.

1
0
Silver badge

Re: Cross platform security kit

Case-insensitivity actually wouldn't be that bad if they allowed passphrases, rather than just passwords. But many users would employ too-short passphrases.

I find financial institutions are often terrible with end-user password parameters. I deal with one that has an 8-character maximum for account passwords, and severely limits the character set. There's no excuse for that; their UIs can certainly handle longer and more complex passwords, and if their legacy backend systems can't, their DAL could hash the longer passwords into ones usable by the backend, which would 1) improve distribution, 2) eliminate the UI as an oracle for evaluating short passwords, and 3) make it much easier for users to employ strong passwords.

(For example: Say the institution's password restrictions are due to using an IMS backend with RACF security and applications that only handle 8-character passwords with EBCDIC printable characters, case-insensitive. That still gives you a password space of around 50^8, or around 45 bits of entropy, which isn't bad if it's difficult or very expensive to test candidates. So you take the user's passphrase, digest it with a cryptographic hash, compress the hash output down to a 45-bit number, and generate the corresponding EBCDIC password by converting to base-50 and mapping bytes appropriately. This scheme would shift much of the security burden from users to the safeguards on the backend system itself. There's no excuse for the organization not implementing something like this; it'd take maybe a day, plus the time to test extensively and deploy properly. It indicates they have no real understanding of or will to provide security.)

Of course the more general issue is that passwords are terrible authenticators, and password restrictions just shift the security problems around. Passwords were originally employed in IT because the hardware of the time wasn't amenable to better authenticators. Now they're completely antiquated.

1
0
WTF?

And the number of people affected is..?

Email encryption, disc encryption - been around for decades.

I don't know anyone who uses it in a domestic situation.

I couldn't point to any commercial organisation which uses it.

Given that a significant (enormous?) number of people publish all their personal details and goings on for general consumption on social media, not may people seem to have any interest in massively secure encryption of any information ,

Corporations in general don't seem to want to digitally sign or encrypt internal email or external email.

Legal professionals (where you might expect that encryption and signing of any electronic communication might be desirable) seem quite happy to accept bog standard emails and documents.

Who actually needs/wants this strong encryption?

Apart from the security services and armed forces (who are the ones everyone is worrying about reading secure emails?

So who does this really affect, apart from people who REALLY want to hide their actions from the authorities and have the time to spend setting up all the infrastructure? Who probably use private keys securely exchanged by physical means.

0
2
Silver badge

Re: And the number of people affected is..?

"I couldn't point to any commercial organisation which uses it"

I worked for a major pharma that mandated encryption for data transfer between any contract research organisation or collaboration.

1
0
Silver badge

Re: And the number of people affected is..?

Companies that build oil rigs encrypt everything at all times.

They even provide engineers with two computers, one to work on and one to do email, etc.

1
0
Gold badge

Re: And the number of people affected is..?

TLS on websites is quite common and I'd certainly appreciate it if my bank would pull its effing finger out and switch to the latest version rather than using some old rubbish with known vulnerabilities.

1
0
Silver badge

Re: And the number of people affected is..?

I don't know anyone who uses it in a domestic situation.

I couldn't point to any commercial organisation which uses it.

While your anecdotal evidence is ... appreciated, it's hardly compelling.

I know of people and organizations that make use of both file and email encryption. So?

I'll agree - these technologies have been available for a long time; the first PEM RFCs were published in 1987, for example. And yes, many people and organizations who ought to use them do not. But that doesn't mean no one does, or that no one wants it, or that no one else would want it if they understood what was involved.

For most users, IT is a maze of frustration, cost (particularly in terms of time), and random reinforcement. Small wonder that the general tendency is to avoid anything that doesn't have an immediate payoff. But that's mostly the fault of IT providers, not end users.

1
0
Silver badge

The real problem with encryption is that it's such a wank to set up. And for an encrypted conversation, you need two people to have gone through the same (onerous) process using the same kit. That's why nobody bothers.

Plus AES is meant to be the best we have and the NSA have had their sticky fingers all over the implementation of that; so it's entirely possible that all the extra brain damage of setting up a secure system is for nowt.

0
1
Gold badge
Unhappy

@moiety

"The real problem with encryption is that it's such a wank to set up. And for an encrypted conversation, you need two people to have gone through the same (onerous) process using the same kit. That's why nobody bothers."

Funny you should say that. The whole "negotiating" a crypto method is called a protocol

That's the bit that has not had serious development over the years, which might explain why we use a few of them (like SSL) and have them handle the grunt work.

Except there does not really seem to be one for email (or VoIP). The problem is if it's not widespread you are stuffed and end up talking to yourself.

1
0
Silver badge
Boffin

FIPS mode

I've found out that those products that allow your SSL to run in "FIPS mode" will automatically discard the crappy legacy ciphers immediately. That's a good thing, even if the protocol hasn't been updated that much.

I hope all the Snowden NSA brouhaha will finally get most organizations off 3DES; DES has been cracked for 14 years and I doubt 3DES is that much secure.

0
0

Opportunistic Encryption

"That's the bit that has not had serious development over the years, which might explain why we use a few of them (like SSL) and have them handle the grunt work.

Except there does not really seem to be one for email..."

Actually, SMTP has a mechanism called opportunistic encryption. The sending server checks the features declared by the EHLO response, and if it sees STARTTLS in the list it does the necessary. While this doesn't encrypt the mail itself wrt the end user, and if there are multiple hops, all would need to be encrypted; for the most part if two organisations run their own mail servers, and they both allow this mechanism, the only publicly visible step of the transmission is encrypted. Those using the likes of googlemail or one of the usual mail hosting companies, don't get a look in of course. This is one of the many benefits of hosting your own internet services.

0
0
This topic is closed for new posts.