Slashdot Mirror

1. Microsoft's "secure" PPTP protocol is inherently insecure, and hence no implementation of it can be secure.
   
   

1. 1. What did Bruce Schneier and Mudge actually do? They found security flaws in Microsoft PPTP that allow attacks to sniff passwords across the network, break the encryption scheme and read confidential data, and mount denial of service attacks against PPTP servers. They did not find flaws in PPTP, only in Microsoft's implementation of it.
   
   

can you say "576-bit blowfish encryption?

I can say it, I cannot do it. On page 336 of Applied Cryptography (2nd ed.), Bruce Schneier says: "Blowfish's key length is variable and can be as long as 448 bits". Not that 448 bits wouldn't be enough though.

Alternatively, for other readers who are prepared to spring for a commercial solution, V-One's SmartGate product springs to mind. It also implements IPsec and is supported on RH6.0.

Counterpane, Bruce Schneier's company, has a few papers on PPTP and IPsec on their website.

I've heard very bad things about pptp, which PoPTop implments. For a sample see this FAQ. Please consider an IPSec solution like FreeSwan for linux or Kame the BSD equivalent.

Some people seem to be recommending PPTP and PoPTop... I've used it before, its a great piece of software. PPTP isn't secure though. Counterpane did an analysis of it. Offline password cracking is possible with PPTP... Counterpane's reccommendation (see the link): "At this point we still do not recommend Microsoft PPTP for applications where security is a factor".

Some people seem to be recommending PPTP and PoPTop... I've used it before, its a great piece of software. PPTP isn't secure though. Counterpane did an analysis of it. Offline password cracking is possible with PPTP... Counterpane's reccommendation (see the link): "At this point we still do not recommend Microsoft PPTP for applications where security is a factor".

The report is here.

The report said that Microsoft's PPTP implementation was broken, not the PPTP protocol itself. Also, Microsoft has since released an updated implementation, which is much less broken.

Before spouting off about how terrible these solutions are and how they present a risk to security, you should read Applied Cryptography (which explains how most of these issues are solved problems) and check to see that the vendors of these products have also read the relavent literature.

-pjf

This isn't beyond current ability. There are `cut-and-choose' protocols, which enable a user to authenticate to a server and obtain a `ticket', which is digitally signed by the server, but without the server knowing the contents of the ticket.

The voting system then takes two rounds: in the first, each voter proves their identity and eligibility to vote and is given a ticket. The ticket can then be provided with the actual vote to the tabulation authority.

For more information, see Bruce Schneier's Applied Cryptography . For a description of a real voting protocol (heavy on the maths), see A Secure and Optimally Efficient Multi-Authority Election Scheme by R.Cramer, R.Gennaro, and B.Schoenmakers.

In this protocol, he sets up an escrow account where people pay for the next recording. When that account reaches a pre-defined amount, he releases the recording. All the released recordings act as advertising for the next one.

Really? Care to say how? Do you mean a backdoor in the program (the source is available) or a problem with the encryption algorithms? Are you a mathematician? Do you think the NSA has managed to prove that factoring isn't NP (which would be quite an accomplishment, esp. for a government organization)? Or, maybe, you mean that they've managed to prove that problems in NP can be solved more quickly (which would be the greatest mathematical achievement in decades). Truth is, if factoring cannot be solved in less than polynomial time, no organization, no matter how many mathematicians they employ, is going to be able to crack PGP fairly quickly.

Heard of TWINKLE? How far ahead of this do you think the NSA might be?

FWIW, I once worked a case for the FDLE, after which they tried to recruit me for their computer crimes unit. They were quite sanguine about encryption, saying they regularly shipped encrypted documents off to the NSA for decrypts, depending on how crucial they were to the case.

Also remember that given access to the private key, keylength is less important than passphrase strength.

It takes some work to use PGP securely, and ultimately, if some TLA wants your cleartext, they'll get it one way (cracking crypto) or another (Van Eyck, TEMPEST).

-Isaac

...in this market.

See Bruce Schneier's comments on this.

Hint: he doesn't like it. And neither do I.

... Security is not something that can be tested for.

Makes sense if you think about it. And it blows a truck right through the "you need a formal spec to test against" premise.

I think Schnier makes much more sense from a theoretical point of view.

From http://www.counterpane.com/crypto- gram-9911.html

The only reasonable way to "test" security is to perform security reviews. This is an expensive, time-consuming, manual process. It's not enough to look at the security protocols and the encryption algorithms. A review must cover specification, design, implementation, source code, operations, and so forth. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure.

No mention of a formal spec.

Go Bruce!

Here it is.

To, partially, answer your question about the number of hits for Twofish and Blowfish, here we go:

There are two types of encryption techniques. There is symmetric (Blowfish, DES, etc.) and asymmetric (Twofish, RSA, etc.). Symmetric algorithms use only one key to encrypt and decrypt information. Asymmetric algorithms, sometimes called public key algorithms use two keys. One public and one private. The public key is used to encrypt while the private key is used to decrypt. Asymmetric algorithms are also usually designed to work in some way as digital signatures or identifiers.

So, first you need to figure out whether you need symmetric or asymmetric encryption. This eliminates an entire catagory. The reason you probably found so many Blowfish hits compared to Twofish is a.: Blowfish is older, and b.: symmetric algorithms tend to be simpler (mathematically) and easier to program.

You can probably find a more thorough explaination of the two algorithms at Schneier's web-page: www.counterpane.com

Ethan Jewett
E-mail: Now what spa I mean e-mail site does Microsoft run again?

... Even if [the technology] were all perfect, the scheme could never work.

The flaw is in the security model. The software player eventually gets the decryption key, decrypts the DVD, and displays it on the screen. That decrypted DVD data is on the computer. It has to be; there's no other way to display it on the screen. No matter how good the encryption scheme is, the DVD data is available in plaintext to anyone who can write a computer program to take it.

OpenBSD can use Blowfish passwords. Not Serpent or Twofish but Blowfish. Why?

Password checking for user authentication is performed in software on a general-purpose computer. Brute-force password cracking can be carried out on specialized hardware. Algorithms that run much faster in hardware than in software are bad choices for password hashing.

The design of Blowfish makes it difficult to speed up in hardware. Twofish and Serpent, on the other hand, were designed for fast hardware implementation. Blowfish is also more scalable, which lets you keep up with Moore's Law.

A paper (PostScript format) on OpenBSD's rationale for choosing Blowfish can be found here. A short presentation is here.

------

OpenBSD can use Blowfish passwords. Not Serpent or Twofish but Blowfish. Why?

Password checking for user authentication is performed in software on a general-purpose computer. Brute-force password cracking can be carried out on specialized hardware. Algorithms that run much faster in hardware than in software are bad choices for password hashing.

The design of Blowfish makes it difficult to speed up in hardware. Twofish and Serpent, on the other hand, were designed for fast hardware implementation. Blowfish is also more scalable, which lets you keep up with Moore's Law.

A paper (PostScript format) on OpenBSD's rationale for choosing Blowfish can be found here. A short presentation is here.

------

Here's a quick extract which pretty much sums it up... "Against all of these systems -- disappearing e-mail, rights management for music and videos, fair game playing -- there are two types of attackers: the average user and the skilled attacker. Against the average user anything works; there's no need for complex security software. Against the skilled attacker nothing works. And even worse, most systems need to be secure against the smartest attacker. If one person hacks Quake (or Intertrust or DisappearingInc), he can write a point-and-click software tool that anyone can use. Suddenly a security system that is secure against almost everyone can now be compromised by everyone."
An extract from the Crypto-Gram Newsletter, ladies and gentlemen. A fine publication.

Here's a quick extract which pretty much sums it up... "Against all of these systems -- disappearing e-mail, rights management for music and videos, fair game playing -- there are two types of attackers: the average user and the skilled attacker. Against the average user anything works; there's no need for complex security software. Against the skilled attacker nothing works. And even worse, most systems need to be secure against the smartest attacker. If one person hacks Quake (or Intertrust or DisappearingInc), he can write a point-and-click software tool that anyone can use. Suddenly a security system that is secure against almost everyone can now be compromised by everyone."
An extract from the Crypto-Gram Newsletter, ladies and gentlemen. A fine publication.

Eventually, the shortage of new ideas will add value to the ones that are there, and mechanisms will come in place to protect IP again.

I disagree here. Creators do not necessarily need to be "protected" in order to be compensated. First of all, there are some people who conscientiously want creators to be compensated, and they will buy (direct from the creators, if possible) even when they could get it for free. Granted, this is a small population, but then again, they would be somewhat powerful, since their preferences would have a bearing on what actually gets created. Selection may not be quite as rewarding as "real" creation, but it nevertheless feels good to exercise that power.

And secondly, check out Schneier and Kelsey's Street Performer Protocol. This thing might actually work (although I still haven't heard of anyone using it yet). Atlas has no reason to shrug if he can get pre-paid for his work. And it doesn't even need IP's "protection".

Maybe there will be a first wave of many creators bailing out. They'll be the ones that the market decides aren't worth paying for. I'm not 100% sure that will be such a tragic loss. If this hurts the media giants who push and promote all that crap, I'm not going to shed any tears, because they weren't the prime movers anyway. Sell that Sony stock.

Claiming that quantum cryptography will bring impenetrable privacy to the masses is rather naive. Decent encryption is already available. How many people use it? The only thing that brings security to the masses is ease of use. If it takes any effort at all, no one will use it. Besides, encryption is only a small part of security.

This is truly a scifi story for geeks... What other tale in the world has had it's own Encryption Algorithym created just to lend plausability to the story?

Stephenson has been criticized by some for getting to deep into the trivial details in his fiction, but personally that's why I read it.

-Tommy

P.S. It's good to see this story is back.

Look at it this way: Up until the Internet, distribution inefficiencies made buying music similar to paying the cover fee to go into a club. If you didn't pay, you didn't get to hear the music, and that's why they could get $15 out of you.

Now the Internet comes along like a hurricane, and all of a sudden the nightclub walls have been knocked down. So now all the bands have to give concerts outdoors, and people can hear them whether they buy a ticket or not. Street musicians exist in the real world as well, and if they're good they can still make money by soliciting donations.

Admittedly, they don't make as much money as behind-closed-doors musicians do, but that's the way the cookie crumbles... the walls are gone, and telling people to pretend they're still up isn't going to work forever.

(note: above analogy probably stolen from here, please don't sue)

I remember way back talking about The Street Performer Protocol There's a lot of talk around here now that you must either give it away or sell it per copy. I really like the idea of SPP. Basically it goes like this: serialize your work. Give out the first few installments totaly free. Use your favorite format: html, pdf, latex. Then put up some shopping cart thing that says, "contribute as much money as you like, but I'm not releasing the next installment until I get $XX". Then take pledges. When you get enough pledges, charge the credit cards and release the next installment. It's true I wouldn't read Battlefield Earth online. It's way to long to read enjoyably on-line. However, a reasonable novel broken up into reasonable sections could easily be read in this fasion. Hey, you could even try to make a community out of it. Put up discussion boards for readers to comment on the sections as they read them. I really enjoy being part of an "as it happens" project. The question then arises about how much to charge for each section and how large those sections should be.

You may be interressed in reading the The Street Performer Protocol, that allow artist to be rewarded in a world where copyright are abolished. http://www.counterpane.com/street_ performer.html

If you talk to some of IBM's ethical hackers you will find out that security is usually a joke. Most places are just wide open.

And physical security is a growing issue. So some state department computer was stolen? If you know what you are doing, getting into "secure areas" is apparently pretty easy.

It isn't just a problem for computers, and it won't be goin g away any time soon.

Cheers,
Ben

I wouldn't blow off Blowfish. I'm not sure about its exportability in machine-readable form (IANAL), but I think the code is solid, and I know it's undergoing and undergone extensive peer reviews / attacks.

Good idea, if the specs of the device are public it shouldn't be too difficult to modify GnuPG to use it.

> Lock the key, not with a passphrase, but with a unique hash from the biometric data;

You can't generate a consistent hash from a biometric - two readings will never be exactly the same and in cryptographic applications a single bit error will render the hash useless.

Instead, biometrics are compared by a pattern-matching engine that can tolerate some errors. This means that your private key will actually be stored in plaintext inside the token and you must rely on physical tamper-resistance to protect it.

> Only real problem would be if you damaged the fingerprint - and there is no reason why the key can't be stored ten times, one per digit.

The real problem is not a damaged fingerprint - it's a damaged or lost token. You must have some kind of recovery mechanism for this case and, naturally, it will also cover the less common case of an injured finger.

For an interesting approach to the problem of secret key recovery see Protecting Secret Keys with Personal Entropy

----

This device (and most of biometrics) is a fraud and merely security through obscurity. Once someone figures out how the card works, then it should be fairly trivial to build a device which opens the card up and grabs your public and private keys.

With PGP and GPG, there's a passphrase to prevent having physical access to the device instantly revealing the private key. You can't really do this with fingerprints (or other biometrics) since the fingerprint cannot be used as a key. The digital image of your fingerprint varies from impression to impression so the device has to ask itself "is this close enough to Alice's finger?" instead of using it as a key.

Even if they could use the fingerprint as a key (perhaps some abstract description of the fingerprint which doesn't vary much), then all you need is a sample of the fingerprint which is fairly easy to obtain. It doesn't even need to be off a live finger - any tests in the device for heat or circulating blood can be bypassed since they can exist only as physical prevention mechanisms, not mathematical mechanisms.

The only really legitimate use of biometrics is if you have secured hardware with trusted guards (i.e., real people) watching that you don't mess with the hardware and that you really are presenting your actual finger or retina. And even this shouldn't be trusted for very important things unless you have several guards at each machine, all resistant to bribes.

Biometrics on a card would prevent only very unsophisticated attacks from people unfamiliar with the cards. If your attackers won't have physical access to your card, then using PGP or GPG without a passphrase is just as secure and more convenient.

Read Bruce Schneier's take on biometrics here.

Nobody is contesting Microsoft's legal right to make proprietary extensions to the kerberos code. The problem is that Microsoft is making proprietary extensions to the protocol and not releasing the specs so that other systems can implement the extensions and be interoperable with Windows 2000. Changing a protocol or interface affects not only the owner/user of a Win2000 box, but also anyone who is on a network with the Win2000 box using the protocol. For this reason Microsoft has a moral obligation to release the spec, more so because kerberos is a authentication protocol- no one is absolutely sure how these changes affect the security of the protocol. Regardless of which side is in the legal right the people who violated the EULA did the world a favor by publishing the spec openly and this is far more important than legal technicalities.

You can get a bit more information from the March Crypto-Gram

My 128 bit keys are looking less secure these days. Actually, it would still take a lot of these little computational engines to crack a key, but just think of an NSA building built out of them :-) (damn, did I just give them the idea?) Bruce Schnider talks briefly about what these types of breakthroughs would mean for encryption in his book on encryption...

Intel doesn't give a damn about whether consumers like it ot not. The serial number was killed before the PIII was even on the market: most motherboard vendors disable the processor id through the BIOS by default.

The reason it got killed was most likely the fact that it is utterly useless for its stated purpose: to provide a secure identity on the Internet. Even if a web browser reports the serial# to a Web site, how is the Web site to know that the user didn't just stick his own header line in? See http://www.counterpane.com/crypto-gram-9902.html for Bruce Schneiers scorching review of its value as a security tool.

He's right in that its more complex and nuanced than the simple "everyone will review this" model; unfortunately I think he's emphasised the wrong and less important nuances.

There's two reasons why TIS wouldn't get feedback from their code: noone is reading it, or noone found anything bad to say about it. My own impression of TIS code was that it is pretty high quality, and there wasn't anything bad to say about it. I don't know of any serious holes reported in Gauntlet.

People do read source, and the point of open source is that you at least have the option. Most people don't sit down and read slabs of code before installing it, they wait until they have a reason to do so. For security software, one of those reasons is that someone has found a breach.

Sure, open source means the bad guys can pick through it and find a hole, but they can do that with standard reverse engineering tools with binary-only releases too. But as soon as someone sees a break-in involving and open-source program, you can both audit it and *fix* it. And a piece of software which has shown one flaw is sure to get a lot more attention. If there were holes in Gauntlet, TIS would be deluged in email after the first compromise.

There's another nuance going on here which Levi completely ignores. Because a developer knows their code is going to be visible for all to see, they're much more likely to keep their code clean (and if they don't, someone else will). A programmer in a commercial environment writing code which will only ever be released as a binary is more likely to hack something now to hit the ship date, with a solemn promise to fix it in the next release (and hoping nobody will find the flaw before then).

Code is complex, and reviewing it is also hard; security makes it even more difficult because security isn't a functional property (see http://www.counterpane.com/whycrypto.html). In commercial environments, code reviews are often skipped in order to keep to schedule, with the rationale of "well, the tests pass". You simply can't test the security of a system - it has to be designed in, and it has to be there from the start.

In other words, he's right that programs like ssh is large and complex, and may well have subtle flaws. But there's absolutely no reason to think that a similarly sized closed-source program won't have similar problems; my feeling is that it is more likely, because the closed source commercial model precludes the possibility of code-review at several levels (we don't have time, noone else will see the code anyway). The open source model encourages code review by

• publishing the code
• often not having commercial time pressures to release it
• putting the reputations of the developers on the line, and
• making it easier to respond to any attacks in a timely and decentralized manner.

J

The threat isn't that your card will get compromised in route (today), but rather that the company you are buying from will be storing your credit card number on a publicly reachable server running an insecure service.

If you'd like to learn more about how crypto works, and keep up to date on it, I'd recommend checking out www.counterpane.com (where Bruce Schneier will tell you to buy Applied Cryptography (which is a good read, and makes a good armrest, too).

Information wants to be free

--

Interesting analysis. And the central servers which had to be secure were running NT...

Interesting analysis. And the central servers which had to be secure were running NT...

Note that they did not publicize it in any way. They just set up the system and left. Not exactly entrapment.

SDSC honeypot Paul

For Plasmoid: the RSA FAQ us a really good place to start, esp. if you've heard a lot of crypto-talk, but gotten lost among the alphebet-soup anagrams and what-means-what. Also, although you've probably been told this a cazillion times already, Schneier's Applied Cryptography is a helluva book-- comprehensive and well written-- worth every penny. He also writes a newsletter, The Crypto-Gram. Backissues are availible at the Counterpane website. You also might want to check out newsgroups like sci.crypt.

That's all I gots for you, kidd-o. Good luck on the prog.

Finally, here are further links to, for example, the crypto law survey which will give you an idea of the legality of Crypto in various countries.

Good luck, and we will look forward to seeing your report if you choose to post it to the web.
--

http://www.cryptome.org
http://jya.com/crypto-free.htm
Learning About Cryptography
Ritter's Crypto Glossary and
Dictionary of Technical Cryptography
Encryption & Security Tutorial
N.A. Crypto Archives
International PGP site
NSA National Cryptologic Museum
EFF
attrition.org crypto archive
Bruce Schneier's Crypto-Gram

and last, but not least (the archive i developed) ....

PacketStorm Crypto Archives

there are lots and lots of excellent tutorials, docs, glossaries, and links to many of the great crypto sites in the world at all of the URLs above.

for the best info on NSA, ECHELON, misc paranoia, you should first check out Cryptome/JYA. i archived quite a bit of stuff related to your questions at the packetstorm site too - packetstorm.securify.com/crypt/nsa/.

feel free to email me directly if you like too. over the years, i have had some interesting experiences with the NSA, BXA, etc - primarily regarding my hosting of crypto archives, and personal investigations of NSA, ECHELON. if you want to discuss these things, get the pgp key for ken.williams@ey.com from www.keyserver.net, and send your key(s) and crypted msgs to tattooman@genocide2600.com

Read Bruce Schneier's Cryptogram newsletter.
Bruce Schneier's hotlinks.
Look at Cryptome. Lots of information about Echelon, the MPAA/DeCSS issue, laws, export controls...
Mach 5 cryptography archives.
Designing Secure Software.
Simson Garfinkel and Gene Spafford's book Web Security and Commerce is a very good introduction to cryptography and security issues.

Read Bruce Schneier's Cryptogram newsletter.
Bruce Schneier's hotlinks.
Look at Cryptome. Lots of information about Echelon, the MPAA/DeCSS issue, laws, export controls...
Mach 5 cryptography archives.
Designing Secure Software.
Simson Garfinkel and Gene Spafford's book Web Security and Commerce is a very good introduction to cryptography and security issues.

Read Bruce Schneier's Cryptogram newsletter.
Bruce Schneier's hotlinks.
Look at Cryptome. Lots of information about Echelon, the MPAA/DeCSS issue, laws, export controls...
Mach 5 cryptography archives.
Designing Secure Software.
Simson Garfinkel and Gene Spafford's book Web Security and Commerce is a very good introduction to cryptography and security issues.

NIST recommended that 256-bit ECC key lengths be used for equivalent security as 128-bit AES, and that 384-bit and 512-bit ECC be used for 192-bit and 256-bit AES. The rough estimates of RSA key lengths for equivalent security are 3072 bits, 7680 bits, and 15630 bits. Imagine the performance degradation incurred with RSA implementations at these key sizes, even with e=3!!

It is generally agreed that ECC private key operations (signature generation and decryption) are faster than RSA private key operations. It is also generally agreed that ECC public key operations (signature verification and encryption) are slower than RSA public key operations when a small encryption exponent (such as e=3) is used.

Bruce was lashing out against vendors who disclose a security expolit merely to plug their own product.

He clarifies this point, and promotes Full Disclosure in the next issue of cryptogram.

He also dismisses the points you made in your posting.

It was the February issue that discussed this. I agree with you and him, and I think Netscape could avoid this whole row by promising a fixed "sunset" after which bugs will be publicized no matter what. A month should do it - most security problems that can be fixed with patches at all seem to be "d'oh!"s that get fixed very rapidly after identification.

I would recommend that all open source projects do the same. If you spot a security bug in the Linux kernel, or Apache, or sendmail or whatever, let the maintainers know quietly and give them a chance to announce and fix in good order; tell the world only if this procedure doesn't seem to work.
--