ENCRYPTION NOW!

[Raman]

I have only one reservation about Linux as it is usually implemented for ordinary (technically unwashed) users: Applied encryption is not up to MS Windows standards; or to put it differently, MS Windows platforms offer easy-to-implement strong encryption for ordinary users, and Linux does not.

Let me explain.

1. On Windows 98 SE and later platforms you can use JETICO's BestCrypt to encrypt files, encrypt entire disks, and what is possibly more important, with JETICO's BestCrypt you can encrypt your Windows SWAP file, all within the rubric of 448 BlowFish, and beyond. http://www.jetico.com/

2. On Windows 98 SE and later platforms you can use PGP freeware 602i to encrypt files and entire disks (but not your SWAP file) using the strong encryption provided by the muscular PGP 602 international release.
http://www.pgpi.org/cgi/download.cgi?fi ... re602i.exe

3. The Finnish entity LBA Linux (formerly SOT Linux) was about to release a beta version of LBA Linux R3 in April-May 2005 when the project was canceled for reasons unrelated to the viability of the R3 Linux release then under development. To this end LBA Linux published the following statement in February 2005:


"Security-conscious notebook users will appreciate the hard disk encryption feature of LBA-Linux R3.

"In earlier versions of LBA-Linux, individual users could have a single encrypted folder. LBA-Linux R3 extends this idea to the entire hard drive.

"'The entire file system can be locked with a password', explained SOT Project Manager Aleksei Rovenski.

"'It's an extra layer of security. Even if an encrypted computer is stolen, the data stored on it remains locked down. No information can be retrieved from the hard disk without the password. It will give LBA-Linux users peace of mind, knowing that their sensitive files are protected. It's a privacy thing.'"


4. Through a Finnish source I was able to obtain an early ISO copy of LBA Linux R3 alpha and the darn thing worked, which is to say, the entire Linux filesystem was indeed encrypted and the Linux R3 OS ran at least as fast as my release copy of LBA R2. Unhappily my technical sophistication is not up to describing how LBA Linux R3 accomplished this feat, but I can say that the resulting LBA R3 ISO installation worked very well indeed. Although it must be allowed that an unsupported alpha release of LBA R3 is not to be used everyday by the technically unwashed, like me.

5. Based on my experience with Windows JETICO BestCrypt and Windows PGP and Windows PGD-Disk, and my continuing happy experience with LBA Linux R3 alpha, I can say that this level of encryption works, that it does not slow the computer noticeably -- or at all, and that this level of SWAP encryption, disk encryption, and file encryption is fast becoming a necessity. Parenthetically, it is safe to say that the average computer user and or average Internet user is now more than fully qualified to say why it is that this level of encryption is fast becoming a necessity.

6. Ergo, Puppy Linux should offer encrypted SWAP files, encrypted disks and or filesystems, and encrypted files. For reasons that ought to be perfectly clear. And it is clear that given currently available software, as proved by the early LBA Linux R3 alpha release, as well as proved by the JETICO BestCrypt and PGP freeware packages described above, the everyday encryption of SWAP, OS filesystems, and ordinary files is or ought to be available right now.


Hail Puppy!

Raman

[Flash]

I'd like to point out a disadvantage of encrypting everything: get one bit wrong anywhere along the line and the whole hard drive may become a garbled mess. If a hard drive is not encrypted it is possible to recover much of the files on it even after they have been partially overwritten, for instance, or if a few bits have become corrupted here and there. Encrypting removes much of this comfort factor, so think carefully before you decide to encrypt everything on the hard drive.

Puppy has bcrypt, which can be called to encrypt individual files, and Lobster I believe has developed a front end for it called 007 Blowfish in the Additional Software forum.

[Raman]

I thank Mr. Flash, Official Dog Handler, for his prudent cautionary heads up re encryption of the entire hard disk. Yours is sage advice, of course, but with the continuing use of individual file encryption, and especially with the use of multiple ongoing copies via Puppy's multisession facility, for example, the risks you summarize are minimized or eliminated. Or so it seems to me.

In many circumstances the advantages of full hard disk encryption are overwhelming and legion, and in any case, if a Puppy user is aware of the need to regularly backup files and directories with encrypted copies, I say caveat emptor.

Thank you for your caution.

ENCRYPTION NOW!

Hail Puppy!

Raman

[rarsa]

Raman,

First:
Your target is missplaced. You compare Windows v.s. Linux as if the functionality you described was inherent to the platform.

I have Windows XP in my computer, I searched (tonge in cheek) and did not find any jetico or PGP 602i anywhere in my computer.

Second:
I think that your post should go to any of the following:
- Jetico
- The people that implemented PGP 602i
- The developers of the file systems (there are a multitude of file systems in linux)
- A linux security forum.

Third:
Your post is quite demanding. Please notice that being demanding in an opensource forum is plain rude. You seem to be a polite person so I think it's just a cultural missunderstanding.

In the open source world if you demand something, you'll be told, as I am doing right now, to implement it yourself, to hire people to do it for you or to contribute in any way to the projects that are working on that.

Actually in some forums not as newbie friendly as puppy, you would get flamed and atacked. (please don't take this post as a flame)

So, to roundup:
- The current incarnation of Puppy does not claim to be deemed to the people that require high encryption.
- When you have an idea or requirement, its better to post as a sugestion than as a demand.

P.S. If it was a cultural missunderstanding, please change the topic of your post and proper case it so it does not sound as if you are shouting in a demanding tone.

[bombayrockers]

Raman you can find how-to's and more about encrypted file systems from
http://www.linux-sec.net/FileSystem/. To have the entire hd encrypted you would most likely have to have the fs modules or support compiled in the kernel. Because puppy was made for the average user to do such a thing would be fatalistic at best.

[Raman]

Dear Mr. Rarsa,

Thank you for your observations with regard to my ENCRYPTION NOW! post.

Permit me to respond to the following:

1. I do not compare Windows vs. Linux as if the encryption facility I seek is inherent or not inherent in the OS platform in question. You misunderstand my thrust. Both Window and Linux in their many flavors can provide strong encryption of SWAP files, filesystems, and individual files. Both Windows and Linux as OS platforms can do much of what is demanded of them, given requisite development. Presumably the developers of Puppy can provide strong encryption if they and their end users think that strong encryption is useful.

2. I do not know what to say about your observations re JETICO and PGP 602i not being on your Window XP computer. What sense are we to make of it? Is this a string of non sequiturs?

3. Why would I post my thoughts to JETICO? Or to people who implement PGP 602i? Or to developers of file systems (numerous file systems that there are)? Or to a Linux security forum? I am speaking to a specific Linux flavor -- Puppy -- which I believe is superior to many other flavors, possibly to all other Linux flavors -- certainly for my purposes, so naturally I hope to suggest improvements that I and possibly others might find useful. That is how operating systems improve and grow, by being responsive to people who use them.

4. I am not demanding anything when I speak about encryption. I am merely suggesting possible improvements to an already excellent operating system. Where exactly is the harm in making suggestions? In any case, I believe the heading of this portion of the Puppy forum is called "Suggestions" -- right? Should we rename this portion of the Puppy forum "Demands"? Where does this confusion come from? There is no "cultural misunderstanding" here, though there is obvious confusion manifest.

5. Puppy Linux can provide any facility to its end users that its principle developer and his associated developers think useful or proper, which can include strong encryption. Where is the problem with strong encryption? What is the problem with strong encryption? Why is the problem strong encryption? Should Puppy remove its several firewall options and become more vulnerable thereby? Should Puppy remove its f-prot antivirus and become more vulnerable thereby? Should Puppy remove its advertisement blocking? And so forth? And so on? Should Puppy evolve into a weak and vulnerable OS? Would that make Puppy Linux a better OS? Perhaps Puppy Linux should revert to an earlier atavistic form? Perhaps become the functional equivalent of Windows 3.1?

Let me restate my suggestion again. I believe that Puppy Linux would be improved for many of its end users if strong encryption were available as an option for its SWAP file or partition, for its entire filesystem, and for its individual files. As an option. Just like using a firewall is an option. Or using f-prot is an option. Or using Mozilla is an option.

Hail Puppy!

Raman

[Raman]

Dear Mr. Bombayrockers,

Thank you for the information about how-to's relative to encrypted file systems. I will certainly look into http://www.linux-sec.net/FileSystem/.

I am not informed as to the possible difficulties of compiling the Linux kernel in order to achieve strong filesystem encryption, but I can tell you about how well the 2005 LBA Linux R3 alpha OS worked with its strong filesystem encryption, which is very well indeed. Beyond that, I based my suggestions on the experience I had with Windows 98SE and its implementation of JETICO's BestCrypt encryption of the Windows SWAP file and the creation of wholly encrypted disks -- entire filesystems, combined with the Windows 98SE implementation of PGP encrypted disks and files, as well as the apparently successful implementation of filesystem encryption (including SWAP) of the early release of LBA Linux R3 alpha -- to restate my Linux experience.

My point is this: If filesystem encryption is useful for enough end users, which I believe it is, and if the difficulties involved are surmountable, about which I have no informed opinion, then I propose that Puppy Linux would be a better OS if such a facility were available as an option.

Firewalls were once thought to be a needless accessory that mostly slowed Internet response. AntiVirus and antispyware programs were once thought to be adding needless operating overhead to an otherwise overstressed processor. Advertising blockers and related programs were once viewed as luxuries. But no more. Obviously the Internet has changed and with it the need for Internet protection. End users have become vulnerable, and by now even the least knowledgeable know it. So maybe Puppy should blaze the trail to filesystem encryption and thereby gain an extended following.

I note with interest the growing emphasis in filesystem encryption now found in the several BSD flavors. I note also the growing body of Linux literature and technical commentary dealing with filesystem encryption. Especially in Germany. And in Russia. And in Canada. And in Scandinavia generally. Not to mention in Poland, in the Netherlands, and in the Czech Republic. So maybe now is the time for Puppy developers to look into filesystem encryption. After all, Puppy is ahead of the game in ease of use -- it certainly is for me, which gives Puppy a huge boost in "marketability" in the crowded Linux game, and adding filesystem encryption as an option would only increase its marketability.

Have you noticed the rapid rise in Puppy's rank on Distrowatch? http://distrowatch.com/ Puppy now ranks 20th out of 100. The reason? Ease of use; absolute power; small size; high reliability; broad software functionality; rapid response to user needs; friendly and informative Puppy forum. And soul, cute little Puppy has soul. So let's add filesystem encryption and dish the Linux competition.

Hail Puppy!

Raman

[rarsa]

So let's add filesystem encryption and dish the Linux competition.

Now we are talking. Go ahead, add it... although... What Linux competition? Am I missing something? I thought that Linux had evolved through cooperation, not competition.

One last thing as I don't want to continue the discussion, justs for clarification.

I am not demanding anything...Where does this confusion come from?

From here:

ENCRYPTION NOW!

Upper case leters are conventionally used to denote shouting. The word NOW implies urgency. Where I come from, shouting the word NOW is a demand. Put it differently: If when I was a child a teacher would say "I SUGGEST YOU COME HERE NOW!" I would surely interpret it as a demand, wouldn't you?

I do not compare Windows vs. Linux as if the encryption facility I seek is inherent or not inherent in the OS platform in question

You are indeed, wether you realize it or not:

<Linux> Applied encryption is not up to MS Windows standards

In this sentence (and others) you clearly make a comparison between windows and linux. The examples you used are third party solutions, not Windows standards.

[Raman]

I must amend my previous statement about Puppy's Distrowatch ranking. I said Puppy ranks 20th out of 100, which is currently true for the last six months. But Distrowatch's current ranking for the last 30 days puts Puppy at 16th out of 100 distributions.

Puppy Linux shot to 16th place for very good reasons: Puppy works, no matter what, right out of the box; Puppy's small size, and power, and wide range of functional software; Puppy's ease of use -- Puppy is very easy to use; and of course its intuitive desktop sells Puppy instantly; then Puppy works with Windows, all of Windows including XP, and Puppy is responsive to user needs -- quick to adapt to user needs; Puppy has a friendly and informative website and very friendly and very informative forum; and soul, let's not forget Puppy's seductive soul, our cute little Puppy has tons of soul. But then there is the unusually creative gaggle of Puppy developers. And the list goes on and on.

Hail Puppy!

Raman

[bombayrockers]

Raman,
I Have compiled a custom kernel patched for speed and i have found out that compiling the kernel is not difficult but configuring it to get the right results and selecting the right modules is difficult unless you know what modules are needed. I used how-to by Staffan from the how to forum and
scripts by Barry.
_________________
Boosted Puppy Kernel (2.4.29) available
Download Here
KDE for testers available
Download Here

[Flash]

All I'm saying is, think carefully about what it is you're trying to accomplish by encrypting stored information. Encryption is a means of access control, and the encryption key is exactly a password, nothing more or less. The encryption algorithm is a very trustworthy gatekeeper; if you don't know the password you can't make it let you see what it is guarding. Encryption can be too effective as a means of access control. If the information being guarded is useful then the enterprise will suffer for lack of access to it. This often has led to the creation of hidden (hope! hope!) or ad hoc back doors to critical information, to insure access in emergencies when password holders may be unavailable.

I'd like to see an instance where it can be said that encryping stored information was of benefit. If information is not useful, it is better to simply delete it.

In short, encrypting stored information as a means of controlling access can, I would even say inevitably will, lead to a false sense of security. Of course, "security" is another highly abused notion, but that's another rant.

[Pizzasgood]

It isn't a well publicized thing, but Puppy does have the ability to encrypt the entire pupfile. You have to remaster for it to be enabled though. The file isolinux.cfg is the file that makes the boot-menu and defines the size for the pupfile. You can edit the line that creates the pupfile to have it ask for a password. Then when you boot it will ask for a password, then make an encrypted pup001. I guess you can't use an already existing pupfile, but you can rename it, boot, then mount and copy it over.

[gliezl]

The file isolinux.cfg is the file that makes the boot-menu and defines the size for the pupfile. You can edit the line that creates the pupfile to have it ask for a password. Then when you boot it will ask for a password, then make an encrypted pup001.

How do you do this?
Thanks!

[syzygy]

few years back, when i had win98 on laptop, i came across some program that promised to encrypt your entire hdisk.

if you googled the prog's name, half said it was a virus, & other half said it was a real encryption prog. being curious i went ahead & ran it. it came up with some sort of ominous warning saying something like ..."are you sure you want to proceed? other sites warn that this is a virus, but it's not! this program will encrypt your hdisk so not even cia will be able to break!".

result was i had unusable, encrypted hard disk! had to reformat, etc. it also put in tiny extra partition that i could never get rid of with fdisk etc.

i still think it really was a legit encrypt prog that i installed wrong, or something.

what'd i learn? caveat emptor, (even for freeware!), & curiosity killed the hdisk, & i never really needed any encryption.

[Pizzasgood]

I ment to say how in my post, but I didn't have time to find it (and couldn't recall exactly from memory).

In isolinux.cfg, you find the line that sets the pupfile

Code: Select all

PFILE=pup015-none-262144

and change the "none" to ask

Code: Select all

PFILE=pup015-ask-262144

Keep in mind that once the password is set, it can't be changed.

[dulac]

Hi,
Some corrections are in order:

I'd like to point out a disadvantage of encrypting everything: get one bit wrong anywhere along the line and the whole hard drive may become a garbled mess.

This is not quite so. It depends on the mode the cipher is implemented.
There are several modes for ANY block cipher (a byte is a block, bit-by bit is sequential)... and some are just like described. But not all, nether they are the most used...

Modes are based on feedback from last block ciphered... to rotten the plaintext BEFORE using the cipher (and thus avoid dictionary attacks).
Using a feedback mode is NEEDED in any serious applications, though the reverse is not true: using them is not prof of a good/safe implementation.

The choice of the Mode depends of the desired properties of the ciphered text. This means one can choose a method that a dirty block only causes the lost of the second block... because the previous feedbacks the error... or a mode were a rotten block cascades the error to all blocks following the error.

You can find a descriptionn of CBC (for the 1st case described were just the second block is affected) at my site... in the file http://www.factor-h.net/quick/security_notes.txt ...

I've developed in the '90s a general (and simple) method to expand any cipher in the same family of Blowfish (Feistel ciphers) to ANY multiple of half the original block cipher size. It is placed at http://www.factor-h.net/quick/dna_method.txt

Example: Blowfish is a 64 bit cipher, thus in can be expanded to 32xN were N is an integer from 2 up to the infinit in increments of 1.

This means that we can use blocks of 512 BYTES (not bits), or if you like,
blocks of 4096 bits (a full sector block) .... Or bigger if other Block sizes are used. Using such a beast ALL 512 BYTES would be destroid with the failure of a bit. But would be faster than Standart blowfish as instead of 16 loops we would only need some 8 (doubling the speed).

Using standart Blowfish (64 BIT blocks= 8 bytes) we DO NEED to use a Feedback mode, so a method to input a starting value to the rottening process is needed. (These - the seeds - are usualy random, but the real need is that they do not repeat). We can use the sector number - It is enough - But that number MUST NOT be lost (Remember it is not stored as in the case of a file - We are talking of sectors).

So a good crypto file system only has, as obligations before the ciphering, to garantee that the seed (called Init-Vector) will be the same when deciphering, wich means: any moving of a block MUST be correctly decrypted with the correct seed AND ONLY then encrypted for the new sector with another seed (the new sector number).

You must not confuse the seed (I.V.) with the password (PSW) wich should be called Passphrase due to its size (No hash is needed for the same reason).

Hope this clarifies the subject.

---

So ther's no reason not to use strong with an hard disk, it depends on the implementation. And I would like very much to see a 512 bytes block being used.

If , personally, I have no worries about bit losses in HDs... as HDs are usually very reliable, until they fail miserably on full sectors. Note this his is just a guess as I'm not informed about they HDs hardware failures. And even less on software failures wich I suspect to be more dramatic than a bit loss.

I'm a little worried is with Flash drives and even CDs...
AFAIK, they can cause a problem with a probability (hardware only) proportional to the read/writing of the most used sectors.

I think it is up to the user to decide, but he should informed... and that is usualy the worse part (and he is also the weakest link) of any security issue...

Regards,
Dutra de Lacerda.

[dulac]

Hi, again

Encryption is a means of access control, and the encryption key is exactly a password, nothing more or less.

Thi is not correct, by any means. I'll explain:

A password, or better: a passphrase, are just text.
And as a text string can get much more BYTES that those avalabe in the Key. Example: A 20 bytes password means 160 BITs. We could be using a 64 bits cipher. Not desiring to lose the entropy in those 160 bits (wich is only 40 to 60 bits of entropy, in english) we need to compress those 160 to 64 with a minimum loss of entropy. The solution is to HASH the passphrase. This is only not needed IF the key is bigger than the passphrase, as with Blowfish (576 bits).

As seen, a cipher Key (used) and the password(INPUT) are diferent subjects, not to be confused.

These are implementation details. So it's natural to confuse the meaning of each. But (still) they are important because they reflect the reality of the process wich is an important part of the whole security process.
It's in our own interest to be weel informed in order to not to make mistakes, be us users... or implementors.

Regards,
Dutra de Lacerda

[dulac]

if you googled the prog's name, half said it was a virus, & other half said it was a real encryption prog.
The result was i had an unusable, encrypted hard disk! had to reformat, etc. it also put in tiny extra partition that i could never get rid of with fdisk etc.

Was it KOH ?!? Most probably.
This was a DOS program for FAT16 that used virus tecnology to ease the tuse of the program. It was an excelent program.

Simply put: A FAT16 tool used in a FAT32 would do just that: Trash the disk. But was no KOH fault, just used in the wrong place. KOH was neer upgraded to FAT32. There was no user base (no interest) in keeping it.

I have the KOH sources, and they are very good.
DOS allowed good and simple code.
I certaily would like that Linux could be made simple in is complexity.
Maybe its me who do not know enough about the hierarquie of inner processes.

What I would like to see is this:
Low level reading/writing -> trough a cipher
Middle level -> (mount points) -> None to simplify
High level access -> changing the key according to the place.

1 - This way home-dir access could be ciphered to the user.

2 - And Root access could be tweaked with the need to get real access, so to invalidate intruders access - This would be the tricky part.

A crypto-system is not a panacea: Any intruder controling a session would get acces tranparently as if no crypto existed.

Regards,
Dutra de Lacerda.

P.S. - Are we off-topic?!?

[dulac]

Keep in mind that once the password is set, it can't be changed.

Unless a table is used. That is implementation dependency.
Not a result of ciphering disk access.

I'll explain:
Being your Password: P1
Next Passsword : P2
Being the stored Key: S1
... changed to : S2
And the REAL Key : KK

We cam implement the system so that
The Input P1 changes the stored Key S1 to KK
Then to change P1 the system would just encipher KK with the New P2 to get S2 ... Once S2 in place only P2 would give the needed KK. Presto!

As simple as that...
The stored Key is just the mean to get the real key.

Regards,
Dutra de Lacerda.

P.S. - The algorithms are very simple.
Is there a system programmer to meke it work?!?
Unless it already exists. (Ooops!)

[Flash]

dulac,

Thank you for setting me straight. I just assumed that encryption algorithms could not recover from errors. As usual I didn't check my assumption before I shot my mouth off. I suppose it is closely related to the subject of error detection and correction?

As to the correspondence between passwords and encryption keys, and the general description of encryption as a gatekeeper, I must hold my ground. Perhaps I did not make it clear that I was speaking in the most general terms from the user's point of view. To someone who wants to keep his information from being read by prying eyes, all that matters is that the encryption algorithm must be given a secret, doesn't matter to him if it's called a password or encryption key, before it will allow the information to be seen. The actual details of encrypting or decrypting the information do not matter to the user. All that matters to him is that the encrypted information cannot be read by anyone without the password/key.

Given that my assumption, about how users generally view the subject of encryption, is true, it seems no exaggeration to describe encryption as a gatekeeper, and the encryption key as just another kind of password. After all, you don't ask what goes on in a gatekeeper's mind when you give him the password, you just expect him to let you at the goodies.