Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

IReadFAks

TS wrote:

Actually I went back and looked at my private key files. PuTTY is kind enough to include a comment line that looks like this if the key has been encrypted:
Encryption: aes256-cbc


... or this if the key has not been encrypted:
Encryption: none


If it says it's encrypted, then the ascii that follows is binary that's been converted to printable form (probably via base 64 or something similar. This is done so transferring the key (by voice, copy-and-paste, or just copying the file across mediums that may not always correctly handle binary) is easier.


Thank you for the clear explanation. My problem was that both the public and private parts of a password protected key looked the same to me - like ASCII text. I didn't understand about the base 64 conversion of the private portion. My googles didn't help because of using the wrong search term ".ppk file format". That's why I came here to ask.

Thanks agaom. (The second word is the private part).

:-)
martin

TS wrote:

If it says it's encrypted, then the ascii that follows is binary that's been converted to printable form (probably via base 64 or something similar. This is done so transferring the key (by voice, copy-and-paste, or just copying the file across mediums that may not always correctly handle binary) is easier.

Exactly :-)
TS_

Actually I went back and looked at my private key files. PuTTY is kind enough to include a comment line that looks like this if the key has been encrypted:
Encryption: aes256-cbc


... or this if the key has not been encrypted:
Encryption: none


If it says it's encrypted, then the ascii that follows is binary that's been converted to printable form (probably via base 64 or something similar. This is done so transferring the key (by voice, copy-and-paste, or just copying the file across mediums that may not always correctly handle binary) is easier.
TS

I really don't see what this has to do with WinSCP, but perhaps I can illuminate things anyway.

As for the MFT: the OS is simply trying to allocate disk space as efficiently as possible. It has no idea whether any particular data is sensitive or not, and the proper tool to address that is EFS. The filesystem is no less secure because of the choice to store small files in the MFT. Filesystem access controls still apply.

The kind of "security" you seem to be asking about is what the filesystem could do to make it easier to dispose of your hard drive, without worrying about its former contents being readable. NTFS doesn't care about this kind of security because it doesn't matter. At the end of your hard drive's life you'll either destroy it completely or you'll overwrite all its contents with a low-level tool that doesn't care about formatting, MFTs, filesystems, or anything else.

Now let's address key encryption. If you in fact provided a password to puttygen.exe then the key IS encrypted. The fact that quasi-human-readable plain text bits are wrapped around an encrypted binary blob does not change the fact that the binary blob itself is encrypted and essentially unreadable without knowing the passphrase you assigned it. You can test this by opening the private key in puttygen. When opened, puttygen will prompt for the passphrase.

Essentially what's happening is this: there's a chunk of plain text that says
This is an XYZ type of public key:

ABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABC

This is an XYZ type of private key:
STUFFSTUFFSTUFFSTUFFSTUFFSTUFFSTUFFSTUFFSTUFFSTUFFSTUFFSTUFF


The STUFF is the part that's encrypted, not the plaintext bits surrounding it. (Those plaintext bits aren't secret, anyway.) The public key probably isn't encrypted (I don't remember for sure), but that doesn't matter because it's public. The public part is supposed to be widely distributed and doing so doesn't break the security of the authentication scheme. This is because given the decrypted private key, it's easy to derive the public key. However, given the public key, it's essentially impossible to derive the private key. Perhaps some other people have handy links to tutorials on public/private key authentication schemes and PKI if you're interested in learning more. (An internet search would turn up plenty of results, too.)

If you still aren't sure it's encrypted, fire up PuTTY, PAgent, or WinSCP, and try to authenticate with the private key file. You will be asked for the passphrase, which if you don't enter correctly, will cause the decryption and subsequent authentication to fail.
IReadFAks

Public/Private Key Pairs - Security

I am using WinScp Version 4.0.4 build 386. I use the accompanying programs Puttygen.exe and Pageant in order to generate and deal with the keys.

WinScp works very well but I am concerned that the keys are not adequately secured. Recently I generated a public/private key pair using puttygen.exe and tried to open them with an ordinary text editor. Eureka, *both* files could be opened with a text editor, they both appear to be "plain text". The private key as a "public" section and a "private" section. This is in spite of the fact that the private key is supposedly password protected (I provided a password in the key generation phase).

What don't I understand? It appears that anyone who has access to my machine has access to my private key!

Even worse, if you say, use Servant Salamander to "shred" the files, it responds that it really can't shred them, since being less than about 1024 bytes or so, they are stored in the Master File Table and are inaccessable.

So, my questions are:

1. How is the private key secure in any way if it is stored in easily accessible plain text format?

2. Is the fact that this wretched operating system (XP Pro, SP 2) stores these files in the MFT a further insecurity?

Comments, suggestions, insights welcome.