Incorrect information about Linux

Posted Mar 16, 2004 20:28 UTC (Tue) by hipparchus (guest, #20252)
In reply to: Windows is insecure by design by paulj
Parent article: Mainstream means more malicious code for Linux (SearchSecurity.com)

I guess you are talking about a Linux Distro, and their current implementations, and not the Linux kernel in particular. I can't see how a standard unix-like filesystem would be such a bad model, although in object terms you get a better granularity of security in say Lotus Notes.
Having said that, I can't really see why the fundamental model of security used in say a modern Mandrake Linux distro would be so bad.
After all, any software installed (through the system) is signed.

As I said before I can't see what your problem is with the security model of most Linux distros. I guess you must be referring to the security implementation:

It is true that any password hashing based system is pretty insecure. But I think anything other than One Time Pad is a weak product since it has built in obsolesence: as cpu speeds increase, asymmetric keys need to get longer and longer. A good OTP implementation gives ultimate security independent of CPU speed increase.

My model would be that users are physically given OTPs bundles on Compact Flash or Smartcard or something. The OTP bundles come from a central security place. (sort of like verisign in the asymmetric model).
Further OTPs between a person and, say a vendor, are exchanged via the central security place. As both vendor and user can trust central security place, they can then trust each other.

Unlike the asymmetric model, if your OTP bundle is suspected or known to be compromised, you can flush it and get another bundle from the central security place (physically, not over the net): the big difference is that trust can easily be re-established. If someone brute forces verisign's organisational root certifier (for example with a giant internet hacker supercomputer via backdoor inserted by worm like SoBig etc etc), then someone can make any certificate name under the organisstional root certifier that certifies when you check it with verisign, meaning you don't even have to brute force all organisation certifiers. (unless clients have access to and always check organistaion public keys, but then who do you trust to give you that?).

Until OTPs are used instead of the vile putrid, pathetic excuse for security that is asymmetric keys, then there will be no security.

OTPs are hardly difficult to implement, you can do it with a pen and paper (perhaps with a dice, or just tear up a sheet of numbers and move them around randomly), so national security won't be additionally threatened by them being used by civilians. In fact I'd guess national security would benefit from not having weak security.

Incorrect information about Linux

Posted Mar 16, 2004 21:37 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (8 responses)

Practical problem: One Time Pads are extraordinarily inconvenient. You would have to create a new pad for EACH transaction with new data; password encryption could, I suppose, use one pad per user, but even so, that's a large burden for a system with many hundreds of users. Using OTP for encrypting e-commerce becomes prohibitive.

This is why OTP is not more widely used; it's unbreakably secure, but it's also very impractical for mass use.

Do the math and some thinking....

Posted Mar 16, 2004 22:31 UTC (Tue) by hipparchus (guest, #20252) [Link] (7 responses)

Imagine using a USBKey like a checkbook (in the UK chequebook):

Imagine you got a usb key full of (say 64Meg USB Key) 6000 OTPs (using imagined size of a pad being 100Kbytes.

You put the old one in the envelope, and send it back, or maybe if they are standard parts, you can return them to any local shop that will give you a refund for them (like you used to do with old glass coke bottles).

64 meg would store the equivalent of a vast number of checks, far more than the number of transactions I'd do in my life: and I'm a comparatively high web purchaser/seller.

You could use the "checks" to log in to your email system. A few a day, every day for a year is still only 1000 virtual "checks".

What else could you use it for:
verifying the news site you're looking at is real: twice a day = only 600 in a year.

Even if you looked at 100 websites in a day, that's still only 36,000 authentications in a year.

File downloads - 100 per year maybe??.

And here's the good bit: USB keys of 1 gig are available, and getting cheaper.

On the server side, one user at a bank needing 64M for twenty million customers translates into approximately 1000 terabytes of storage. Given that you can buy a terabyte of storage for about $1000 now, you'd be looking at $1Million. Add on RAID,24x7,hot-swap everything, you're still looking at only $10Million to store the OTPs for 20 Million customers.

Tell me again it isn't possible.

Well, after some thinking...

Posted Mar 17, 2004 13:21 UTC (Wed) by flewellyn (subscriber, #5047) [Link] (1 responses)

It's plenty possible. The question is, is it practical? I still don't think so.

The problem is not storing the keys. The problem is that, in order to work, the (randomly generated) keys have to be as long as the message. Which means that the scheme you propose would work decently for messages known to be a specific length, all the time, without fail. Cheques wouldn't qualify, since some of the fields (such as the payee, amounts, and any info in the "Memo" field) would not be of identical length. The same goes for passwords, absent a mandated standard which required all passwords to be a specified (presumably maximal) length. And as for actual email messages? Forget it.

There's one other problem: centralization. The scheme you propose requires a central authority which creates and distributes the keys: this is a VERY big problem. For one, it creates a single point of failure for the entire system; compromise the agency which takes care of key creation and distribution, and you have complete failure of security. Another problem is, who administers this agency? The government? A business? A non-profit, perhaps? I don't see any such agency which would be completely trustworthy. And, with such a system, the central authority must be completely trustworthy. Otherwise, you have no guarantee that, for example, the One-Time Pads are truly "one-time"; a repeated pad is vulnerable to straightforward cryptanalysis of the simplest sort, frequency analysis, which can be pretty easily brute-forced on modern equipment. To say nothing of the problem of governmental intervention: if an intelligence agency, for whatever reasons, can simply order the authority to turn over keys for specified customers, the encryption provides NO defense against snooping by the authorities. Even to folks like me, who believe government is not inherently evil, that thought gives pause.

No, One-Time Pad is a very good system for sending occasional messages between two trustworthy points in absolute secrecy (say, between the White House and the Kremlin, a la the Red Phone, which does use OTP, or between an embassy and the capitol of a country), but it's not suited to massive amounts of traffic. The centralization and symmetry of the keys creates too many practical problems.

take a hint from SSL

Posted Mar 17, 2004 22:51 UTC (Wed) by hipparchus (guest, #20252) [Link]

1. If customer numbers + secrets are used instead of customer name (remember me talking about a dictionary) then the the check message can be a fixed size very easily. Often Banks have limited length customer names in any case. (but why weaken the encryption by putting in redundancy).

2. Data from a website could be sent unencrypted, and a checksum using variable algorithm could be sent using encryption to verify contents have not been adjusted "in flight").

3. If you have to have a secret variable length message, From memory SLL works thus: After authentication, a symmetric key is exchanged and data exchanged is encoded using the symmetric key. There is no reason why you can't just replace the SSL authentication with the OTP system.

4. Central point of failure: You are misunderstanding me. The OTP system described establishes trust between point A and point B. There is no reason why you couldn't establish trust between B and C,D,E,F,G,H etc etc.
Putting it another way - you could send mail to your ISP and be trusted. Your ISP (say acme.co.uk) could trust a more central system, (like security.co.uk), and so on. The topology could be heirarchical or a huge spiders web like the web is, with authentication to a destination determined through a kind of DNS system. Heirarchical is more efficient for extremely low node failure rates, spider web more efficient in a system where nodes fail more often. (hierarchical is a subset of spider web in any case).

Do the math and some thinking....

Posted Mar 18, 2004 12:03 UTC (Thu) by ekj (guest, #1524) [Link] (4 responses)

Sure it's *possible*. The relevant question though, is if it is *useful*.

Yes, a OTP (correctly implemented, and with correct key-management) is unconditionally secure. But for all practical purposes though, AES, or any other of the modern non-broken ciphers are also secure.

Do you *really* think it's worth spending huge resources to guard against weaknesses in AES in a world where noone has ever lost a single cent due to brute-force cracking of AES, but thousands of people got into trouble of some sort because of bad key-management.

Thing is, the key-management-problem is bigger with OTPs than with all other crypto-systems, especially compared to public-key ones. And the gain from "takes a gazillion years to crack" to "Cannot be cracked" will never be enough to compensate for this drawback.

useful things about asymmetric keys make them weak and AES is weak anyway

Posted Mar 20, 2004 0:29 UTC (Sat) by hipparchus (guest, #20252) [Link] (3 responses)

As you know asymmetric keys are a whole lot harder to make than symmetric keys. The "useful" things about them are that you can distribute a public key, and keep a private key hidden.
The whole principle is that the author keeps the private key, encrypts or "signs" data, and people with the public key can verify the data sent by the author to be his work.
The problem is by the nature of the above system, the keys cannot easily be thrown away. You might have documents all over the web signed by the author, and numerous clients with the public key who you'd have to distribute a new public key to (they'd have to keep your old public key to verify old documents they might have stored, too).

If you start by the premise that you (analogy) change your locks on a regular basis, you're system is a lot more secure.
I've provided a way in which authentication can happen irrespective of symmetry of keys.

GZILLION YEARS TO CRACK AES:
You should know the NSA make ASICs with hard wired asymmetric decode hardware which can decode something like 5000 encrypted messages per second. Imagine a large circuit board with 200 chips like this on it, then multiply by 20 in a 6ft tall 19 inch rack. Then multiple by say 10 6ft tall racks.
So now you're talking decoding 200 million encrypted messages per second, hardly the gzillions of years for one key.

Re: AES is weak anyway

Posted Mar 26, 2004 18:35 UTC (Fri) by robbe (guest, #16131) [Link] (2 responses)

Brute forcing a 128-bit key with 2*10⁸ trials per second still takes more than 26 sextillion (2.6*10²²) years (quite close to what people would term a "gzillion").

Calculating the years needed if computing power doubles every 18 months is left as an exercise to the reader.

Of course this says nothing about a rubber hose, cryptoanalysis, or brute-forcing the INPUT bits to the key (i.e. the possible passphrases), all of which will bring success in less than a century.

asymmetric keys have few solutions

Posted Mar 27, 2004 1:01 UTC (Sat) by hipparchus (guest, #20252) [Link]

Asymmetric keys are far less strong than symmetric keys. Note in the case of AES, the NSA (and perhaps many other people) already know the algorithm.
Therefore you have to brute force only a relatively small number of possible solutions.

What you get in trade off for the lack of strength is .... asymmetry (public and private keys).

I propose using symmetry instead, and totally discardable keys.

read this about DES for example, and go figure about AES

Posted Mar 27, 2004 1:41 UTC (Sat) by hipparchus (guest, #20252) [Link]

Please note AES is in itself a symmetric block cipher of say 128 or 256 bit size. HOWEVER the recommended imlementation for exchange of the cipher is public/private key encryption. (see my above mail about small number of solutions):

out of interest: DES cracker (they said it was uncrackable).

http://www.eff.org/Privacy/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html#howsitwork

discussion on implementation of AES:

http://66.102.11.104/search?q=cache:OKqHzqpn-RcJ:www.parallaxresearch.com/dataclips/pub/infosec/cryptology/guidelines/STOA-Report3-5.pdf+nsa+chips+to+decode+aes&hl=en&ie=UTF-8