Slashdot Mirror

Hmm... "proprietary encryption"?

http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

CD producers have, to a large degree, abandoned the use of the "Compact Disc Digital Audio" ("Red Book") logos after about 2002. Interhack did fairly extensive testing of various CD copy protection systems a while back and found that, among other things, many of the newer copy-protected discs did not carry any of the logos that go along with the Phillips specifications, but instead carry an "Enhanced CD" logo that is licensed not by the producers of playback devices, but by none other than RIAA, the producers of the content.

It's a subtle but very important shift in the business of creating logos that consumers use to determine what it is that they're buying. Where the logo used to be something that would ensure high compatibility among playback devices, the logo can mean whatever the producers want it to mean -- and maximum playback device compatibility takes a back seat to enforcement of certain restrictions.

We made quite a few other discoveries of interest as well, including the error rates introduced by unplayable frames on discs as part of some copy protection schemes by comparison to what happens when a disc is scratched with a metal key. Our testing has been a bit different from that done by others in that we used some special hardware to look at things like the use of wonky pit/land geometry that is "beyond-spec" and how that affects playback in various devices like audio CD players vs CD-ROM readers.

Snake Oil Warning Signs: Encryption Software to Avoid

Last updated 1998, still insightful.

And for the vast majority of users, so does Jabber. It obsoleted the commercial IM systems when that open standard was ratified last summer. The user@host format for referring to specific users isn't going away any time soon.

Likewise, you have to give someone your email address to ever receive email, and if you do that, any and all munging is rendered permanently and irrevokably useless. Get over yourself. Email addresses aren't private, please stop pretending and convincing other people otherwise. You're just giving yourself and other false hope and slowing down the rest of humanity's fight against spam, you stupid douche.

If you're so concerned your email address getting revealed, it really is time to pack up your computer back in the box it came in and send it back to the OEM for a refund.

Is a good place to start if you want to protect yourself against people hawking dodgy crypto.

I used to work at a small company where a guy came in and was trying to get us involved with some dodgy "crypto" product. Management were quite taken with it (he could talk and even had a patent!) but technically it was a load of horse shit with some pretty multicolour diagrams. That FAQ helped me crystalise my objections and the guy was given the heave ho before the company did anything embarrassing.

http://www.interhack.net/people/cmcurtin/snake-oil -faq.html

[Please mod my previous reply down. It's botched.]

There is some information about the algorithms they're using here. That page says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.

Frankly, I don't trust it.

First of all, neither 1024-bit DH nor 128-bit AES actually give you 128-bit security (i.e. 2^128 complexity). For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about Diffie-Hellman, but it's similar in structure to RSA, and experts have been recommending at least 2048-bit keys for new designs using RSA for years, and that's not even to get a 128-bit security level. For a true 128-bit security level, you need something like 6100 bits (if I remember correctly), which most people don't use because it's very slow to do in software.

The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single repeating AES ciphertext block with the entire plaintext datastream, which would be trivially insecure. We really have no way of knowing.

As for authentication, which is often more important than confidentiality (and which may be required for confidentiality)? This is all I could find:

Additional security and integrity is ensured by a calculated HASH checksum that is indicated on the display.

There is no mention of what hash function is being used, nor of what is being hashed. Furthermore, people who talk about "HASH" -- in all-caps, as if HASH is an algorithm itself -- clearly don't know what they're doing. It might just be Vecrotel's marketing department messing things up. Or, it could be a more fundamental lack of expertise within the company. Who knows?

Have a look at the Vecrotel FAQ:

VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.

...

KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS SOURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.

Totally unacceptable.

If those really are "frequently-asked questions", those responses are simply arrogant. The company has clearly adopted a "trust us" mentality. If I was willing to blindly trust other companies, I wouldn't be looking for a secure phone!

Crypto products are like voting machines. If their operation is not independently verifiable, then they simply cannot be trusted.

As an interesting side note, I don't see any FIPS certifications.

I smell snake oil.

Frankly, I don't trust it.

First of all, neither 1024-bit DH nor 128-bit AES actually give you 2^128 complexity. For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about diffie-hellman, but it's very similar in structure to RSA, and experts have been recommending at least 2048-bit keys for RSA for years now.

The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single AES ciphertext block with the entire plaintext datastream. We really have no way of knowing.

Have a look at the Vecrotel FAQ:

VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.

... KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS OURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.

Totally unacceptable.

If those really are "frequently-asked questions", those responses are simply arrogant. The has clearly adopted a "trust us" mentality, which just doesn't work with people who want strong security. I also don't see any FIPS certifications anywhere.

I smell snake oil.

I still have my DESCHALL t-shirt. As I recall, we spent more time arguing about what the t-shirt should look like AFTER the key was recovered than we spent recovering the key. :) Here were my thoughts on the subject back then.

Once again serving as the "missing bit in every /. editor" I'm proud to preseng (geeeeee!) something more about Matt.

He is a very weird and amusing fella ;)

If you really want to help then you first need to learn what a real hacker is and not what the mass media spoon feeds you. One place to start is What Is a Hacker? A good book on the subject is Steven Levy's Hackers: Heroes of the Computer Revolution

Implementing a program that encrypts with an OTP is a no-brainer. Any program capable of doing a bitwise XOR can do it (basically because the algoriths IS a XOR).

There are two BIG problems with OTP:

1) You need a lot of random bits (the good stuff, like this, not your cheap pseudo random numbers). You need exactly as many as your plaintext.

2) You need to securely send a copy to the intended receiver, and make sure the pads are destroyed once used.

Basically, no one does it because it's a real bitch to implement correctly (pad creation) and it's not worth the effort (unless you're using them in a hotline from Washington to Moscow or something like that).

You probably don't want a OTP. If you want something to encrypt your files and recover them with a password, you CERTAINLY don't want a OTP (in fact, you can't have one because the pad is not random, it's pseudo random, generated from the password and thus lacks the important properties of an OTP).

And very important: most companies that sell "One time pad" software usually sell snake oil, so be very careful.

And if you think you can get away with a pseudo random pad, the soviets spent some big time making pads for diplomatic and espionage messages, and made the little mistake of using the pads more than once, you can see the results here.

In firewall terms a DMZ is a subnet off the firewall that will allow traffic to enter your network from the outside. This is the best way to provide services to external entities without compromising the rest of your network.

See this faq to learn more about how firewalls work.

Just for the record, address munging and fake addresses are not the answer. Reporting spam is.

And that is exactly why address munging is considered harmful.

Enigma encryption might have been a great leap ahead and looked completely state of art in the WW2, but today, it's quite trivial to crack. Enigma could be easily bruteforced - just check through the entire keyspace.

It also probably wouldn't stand too long if real crypto breakers who knew their stuff would start their job without knowing anything about the encryption scheme, even. The science has gone so far in recent times.

And an easy way to illustrate: Compare output from Enigma with any modern cipher. Enigma output looks like completely mangled words - the text is garbled, the layout of the message is exposed. Modern cipher output looks like a completely random arrangement of bits, everything completely spread around the message with no point to really take a good grip on. With Enigma, if you know that Nazi guy is always putting "Heil Hitler" at the end, you have already cracked that much of the message.

If the thing looks trivial, then it probably is. If it doesn't, it probably isn't. Of course, this isn't always true in either way.

Now I'll get more coffee so I can start making sense today.

This site has the ancient "Snake Oil FAQ" maintained by the esteemed C. Matthew Curtin. Despite its age, I still find it useful for PHB-types, etc.
JMR

Procmail is your friend. Use it. In conjunction with SpamAssassin, you can filter it off to a folder to go send to SpamCop at your earliest convienence. While SpamCop officially discourages doing so, setting your mail server to reject based on the RBL bl.spamcop.net will save you some work (and money if you're a SpamCop member) by prohibiting mail from sites already reported by several people.

I use exim in conjunction with sa-exim to reject spam that scores high with Spamassassin, and to teergrube the luser. Since I'm the postmaster, I also have sa-exim give all the sa-exim rejected spam to my spam folder to report as well.

I have roughly 30 users. Almost all of them use my site for mail, since doing so is extremely spam hostile thanks to me, with very little inconvienence, if any, to legitimate mailers, which is the way it should be.

On an aside, I also use abuse.net's forwarding service to report hosts infected with viruses to their ISPs. I've been fairly successful, though it could be better. Roughly one third of the ISPs I contact suspend or terminate the user's account for it. I also maintain a net-lsearchable list of the last relay such infected messages go through before hitting my server. Feel free to use it for yourself, it's on my website.

Back when the 'net was young, and there was hope for stopping spam before it snowballed out of proportion, it was hoped that this naive "nip it in the bud" attitude might work. It hasn't. Spammers have proven as resilient as cockroaches, and more prolific.

Keep in mind who is paying for spamming: get-rich-quick losers. There's more than one born every minute. They're typically not successful, but there certainly are a lot of them. By the time one of them has realized they're not "getting rich quickly" and give it up, half a dozen more have started up their own "get rich quick" schemes.

Legislation, anti-spam hassling, RTBLs, threats, ISP cut-offs, they all serve to shut these fools down one at a time. But the population growth of fools far outpaces the ability to shut them up.

I agree that address munging "breaks" how things are supposed to work. The reality of spam dictates that many of us have given up how we want things to be, and instead deal with things as they are. I can't afford to fight every stinking spammer in my inbox, and those are the ones that have successfully run a couple of anti-spam gauntlets. Automated spam reporting tools proved useless to me years ago -- and now the anti-spam RTBL sites are busy collapsing. Bayesian filtering has been mostly effective for me so far, but I still find good mail in my spam box. Changing email addresses helped dramatically at home, but is not an option at work. So, if munging helps reduce the spam, it's just another useful tool in my kit. And if you think address munging prevents someone useful from contacting me, you simply have no idea of the depths of my apathy.

Also, don't munge.

There is actually a group of standards that apply to CDs. The trick is figuring out what exactly is happening on any particular disc. For example, in the official Compact Disc Logo Guide published by Philips, there are different logos to show discs compliant to the following standards:

• CD-DA for Compact Disc Digital Audio
• CD-G for Compact Disc Graphics
• CD-EG for Compact Disc Extended Graphics
• CD-MIDI for Compact Disc MIDI
• CD TEXT for Compact Disc TEXT
• CD EXTRA for Enhanced Music Compact Disc
• CD-ROM for Compact Disc Read Only Memory
• CD-i for Compact Disc Interactive
• CD-V for Compact Disc Video
• Video CD or VCD for Video Compact Disc
• Photo CD or PCD for Photo Compact Disc
• CD-R for Compact Disc Recordable
• CD-RW for Compact Disc ReWritable
• SVCD, Super VCD or Super Video CD for Super Video Compact Disc
• High Speed CD-RW for HIgh Speed Compact Disc ReWritable
• DD-ROM for Double Density Compact Disc Read-Only Memory
• DD-R for Double Density Compact Disc Recordable
• DD-RW for Double Density Compact Disc ReWritable

There is actually a specification for each one of these logos. Also, there is no guarantee that a CD-ROM drive will be able to play a CD-DA disc (per the spec, though the spec says that it would be easy, and it is).

There is an effort underway to understand all of this stuff and to figure out how these things work together, and with various types of hardware. The project has an Open Source (BSD-style license) package called CD Verity that performs some testing of discs. The software is part of Interhack's Digital Media Project and might be of interest.

uses a proprietary encryption scheme

translated:

Some crappy, broken scheme baked up by programmers not professional cryptographers.

I'm glad it is not my venture captial money backing this broken puppy.

Sigh. Snake Oil FAQ or the Crypto mini FAQ and various Cryptogram will remind you, proprietary encryption is very bad.

Whenever I read about military-grade encryption I remember this.

Perhaps this or this may clear things up for you.

Please read the Snake Oil FAQ and you will see the problems.

Vilmos

No doubt it is the "anti terrorist yet homeland security friendly edition" this time around.

-some cypherpunk

InterHack reports that SpectorSoft sends all captured data (this includes the emails) through their own servers. Employers that monitor their employees with this software will also be giving Spectorsoft a clear view of what their employees are doing. Proprietary and otherwise sensitive data are certain to fall into Spectorsoft's hands. Who is Spectorsoft, and why should you trust them to keep your secrets? Read the report here.

InterHack reports that SpectorSoft sends all captured data (this includes the emails) through their own servers. Employers that monitor their employees with this software will also be giving Spectorsoft a clear view of what their employees are doing. Proprietary and otherwise sensitive data are certain to fall into Spectorsoft's hands. Who is Spectorsoft, and why should you trust them to keep your secrets? Read the report here.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them.

The bits in the pad cannot be generated by an algorithm or cipher. They must be truly random, using a real random source such as specialized hardware, radioactive decay timings, etc. Some snake oil vendors will try to dance around this issue, and talk about functions they perform on the bit stream, things they do with the bit stream vs. the plaintext, or something similar. But this still doesn't change the fact that anything that doesn't use real random bits is not an OTP. The important part of an OTP is the source of the bits, not what one does with them.

To anyone who thinks that this is somehow a good system I have two links for you:

http://www.counterpane.com/crypto-gram-9902.html#s nakeoil
http://www.interhack.net/people/cmcurtin/snake-oil -faq.html

Read them and weep at the BS.

http://www.interhack.net/people/cmcurtin/snake-oil -faq.html

The 128 bits Netscape uses are for a symetric key. It takes considerably less bits for a symetric key to be secure, than an asymetric key. (I forget the equivalency, but ISTR that 128 bits symetric is roughly equivalent of 2048 bits asymetric.)


This is a bit dated but there is a section on the key length equivelants between symetrical and asymetrical methods.

http://www.interhack.net/people/cmcurtin/snake-oil -faq.html#SECTION00043000000000000000

Well, of course, if the picture is unique, this is the one-time-pad encryption. In order to decrypt, you have to use the same picture (i.e. the same key).

One-time-pad is so-far the most secure, but it is not very practical in daily use. And make sure you don't use the same key more than once, otherwise, it falls into the same weakness as other encryption.


More info on OTP's:

http://www.interhack.net/people/cmcurtin/snake-oil -faq.html#SECTION00057000000000000000

In terms of security, there are some things that *are* perfectly secure. The one-time cipher is an example of this. Unfortunately, the pad of keys must be synchronized at either end of the communication -- and of course you can't transmit these, so practically-speaking, it's not really an option.

There's a neat document outlining "snake-oil" signs in encryption software here.

I was unable to find a description of the JAWS algorithm on the JAWZ website (JAWS Home Page), now that they have become a security consulting firm. The best I could find was a small redaction of the original JAWS claims here: 4comm DataEncryptor.

I wonder if anybody still has a copy of the original JAWZ claims (quite a hoot).

Ok, I've visited on their site and this is my take. I wouldn't touch it with a barge pole - if it makes RIPA look silly then it may serve some purpose, but not as a viable secure platform. Their entire approach is flawed in any case, good security should be built into all platforms, you shouldn't have to consider changing for what ought to be such a basic facility.

m-o-o-t is an open-design, open-source cryptography project begun to defeat RIPAPart3

This is very naive. You do not 'defeat' laws in code any more than you make crypto impossible by legislation. The two systems are completely orthogonal.

As we consider all present protocols insecure against the new attacks brought about by legislation

The law is not an attack on any protocols, it is a response to using those protocols if anything. You should also see the Snake Oil Warning Signs FAQ where it warns specifically against mud-slinging against existing or competing techniques.

hidden stenographically

I rather suspect that had this site had anything to do with established cryptographers whose opinions I trust (well, I can't find the m-o-o-t team members' names anywhere on the site ("We aren't exactly secret but some of us don't want to be identified") so I'll keep a very reserved judgement on their credentials), it would be spelled slightly better. I've no idea what methods of shorthand typewriting have to do with secure computing platforms... (They get it right on a different page, to be fair.)

There will only be one choice for each type of algorithm ... We think that most programs offer too much choice in this and thus lose security as people don't know what is happening or how secure the algorithms being used are, often they don't know what they are and they may be using eg export grade cyphers

This will potentially sabotage security, not improve it. Assuming they use strong, time-tested, public algorithms, it is still possible one could suffer a fundamental break tomorrow. Unlikely, but possible. Or next week, or next year. If back-up algorithms are used and implemented well, users should not even be aware of the back-up algorithms. One would also hope that no serious security implementer would suggest using 'export grade' ciphers, the fact that they believe this is possible is worrying.

Plod - a cryptographer's term for the Police

The usual Dramatis Personae are Alice, Bob, Mallory etc. I've not seen any serious paper referring to 'Plod' and suspect it's just randomly offensive on their part. Their appeal to authority ("cryptographer's term") is bogus.

we will use the CD as a large look-up table to ensure authenticity of the CD and prevent fake CD's with backdoors etc.,

Don't believe this - it won't work.

we will not do updates due do the insecurity of distribution methods and to avoid incompatibilities

*choke*. So they're going to get it right first time, with absolutely no implementation errors possibly leading to security compromises. I wish they'd publish a paper on that alone, because it beats anything anyone has come up with in 50 years of software engineering research. (Hmm. If you can't trust the update how can you possibly trust the original?)

The system also relies on you trusting your PC, and also possibly the data havens to some extent. We've already seen a story this week about the FBI installing bugs within the keyboard itself - other parts of the system can be similarly sabotaged with almost no chance of detection by the user - this is probably what any clued up LEA would want to do if they knew strong encryption was being used. Remember, if the end-point hardware has been tampered with all bets are off, for any security system.

There is so much more, I could go on all day. The possibility that they might want to make money from this (but are considering using a Free OS, which they might not want you to make copies of - no wonder they don't want to be identified) is mildly interesting. Frankly they could as well be part of a multinational government conspiracy, but rather than get excessively paranoid I think I'll just assume they're seriously misguided.

The bottom line is that there is no straightforward and concise answer to your question. We at AFTI have analyzed a number of encryption systems, and we believe SafeMessage to be more secure than any of the competition. But we can't provide a simple bit-count, for example, because our system encrypts the same data with several different ciphers and keys, some symmetric, some asymmetric from large fields, complicating the math of arriving at said bitcount.

The Snake Oil FAQ (http://www.interhack.ne t/people/cmcurtin/snake-oil-faq.html) has alot to say about this sort of thing.

The annoying thing is that the press pick these press releases up and write an article without any serious investigation of the claims made by the company.

The decision for Quote.Com to change wasn't only based on the "reliability" of the platform.

Their decision was also based on facts like:

• There are more pre-built software components for IIS/SQL server
• Things like XML support are very primitive in PERL, for example.
• MCSEs are cheaper to hire than Unix admin/programmers
• With more, cheaper machines, you can play the "uptime numbers game"

A lot of developers are working on XML support in PERL (there is a Perl/XML FAQ), but you still can't support Unicode. Perl still relies on 8-bit character sets, so we use UTF-8 instead of 16-bit Unicode. Unicode support is neccesary for a complete XML implementation.

You'll also find that MCSEs will be cheaper to hire than Unix programmers. This is partly due to their (general) lack of skills, and partly due to their great abundance. An MSCE course only teaches you how to think the Microsoft Way. I wouldn't trust an MSCE to maintain or write code in C++ or Perl, for example. Without the MFC and a pointy-clicky interface, an MSCE can't function.

However, give the MSCE the MFC and a pointy-clicky interface, and an MSCE can deliver a program faster than a "traditional" developer. The fact that the program inherits all the bugs and mis-features of the MFC is not an issue here. The fact that the program was slapped together without regard for maintenance or robustness is also not an issue here. The issue that Quote.Com chose to focus on was delivery time, not quality of product.

As for the uptime numbers game, it works like this:

If you have 1 Sun server, and you need to upgrade the hardware, you need to shut it down. If it takes 1 hour to shut down, replace the hardware and restart, then you have 1 hour downtime.

If you have 2 Windows NT servers (for the same price as 1 Sun machine), and you need to upgrade the hardware, you need to shut them down. If you do it one machine at a time, and take 4 hours total to replace the hardware, then the server pool still has 0 hours downtime. Windows NT pundits will happily overlook the fact that the individual machines are constantly being overhauled.

In addition, Microsoft introduces the idea of "scheduled downtime". That is - you plan to reboot each machine once a day, to make sure the system remains stable. So twice a day, you have one of your two machines reboot. One machine reboots in the morning, the other in the afternoon. The total downtime of the server pool as a whole is still 0 hours (because you're not counting "scheduled downtime" as "real downtime").

Now combine the MSCE factor with the downtime numbers game factor, and you'll find that you can get away with shoddy code, because when your server crashes, it's not really downtime anymore. The problem of data integrity in your backend database is something for the DBA to worry about. You've got your uptime figures and time-to-delivery figures up there in the top 10. If the DBA complains about data integrity, you sack her and fire someone with a more "can-do" attitude. You don't want slackers in your Microsoft Powered enterprise!

Daily Reboots:

• Win95 prescription: 50mg of reboot daily
• What's So Bad About Microsoft?

Consider the following points:

• "her code can encrypt a letter in just one minute - a widely used encryption standard called RSA would take 30 minutes." No justification is given, and indeed we all know that PGP does not take 30 minutes to encrypt e-mail.
• "She has also proven that her code is as secure as RSA." Again, no justification is given. Proofs of correctness are rare in computer science. Moreover, there are many different levels and definitions of security in the field (known plaintext, chosen ciphertext, complete break, etc.) and this quote does not cite any of them.
• Consider the source: Most of the material is quoted from her father.