New Security measures.

[ferigor]

So I've been having a weird problem with my pop up key board thing.

It comes in, I put in my password, hit connect and it disconnects me for typing in the wrong password. After it boots me out, I go back in (saved password and what not) and connect no problem. I haven't had to change the password, and I haven't had any problem connecting. Worth reporting to anyone? I doubt it, but thought I'd ask.

[AoshiZ]

Furthermore, The most important aspect that you do not understand is that the process is handled entirely client side (for the unique system identifier). The way the private key is generated must be a secret. This is why this algorithm must be secret. If it were known then people could simulate the process and generate the keys. This is why I said proprietary. Please look into why keys need to be secret.

Here is an article about key generation that might help:
http://en.wikipedia.org/wiki/Key_generation

Thank you for telling me exactly what I didn't understand. If I didn't have you or wikipedia to explain it to me, I'd have to resort to the half dozen textbooks I have in my living room from school.

Meanwhile, my entire point is that saying that using a proprietary algorithm does not, in the long run, provide you with any measurable extra security. If you are relying on the fact that no one has seen your process yet in order to protect your data, you're already screwed. NOTE: (I'm going to bust out bold for this) proprietary algorithms are neither necessarily strong or weaker. Telling people that something is better because it is proprietary is balls. Something is better because it can be demonstrated to be.

PS: The method of generating the key does not have to be secret. All that matters is what you feed into the algorithm is secret and the algorithm output is sufficiently complex.

I'm sorry but you're not really understanding what I'm saying. All you're saying is proprietary is dumb proprietary is weak. You haven't read what i have been trying to say and you haven't noticed that i agree'd that public algorithms are the strongest.

Let me clarify because it sounds like you don't understand what i'm saying. An encryption process is an entire process of hiding information and part of that is the Key Generation. The key generation must be secret. The process of which the key is used to encrypted does not. But because a Unique Identifier for the system is generated with POL, this process is completely client side. That is why the process in which the key is generated must be secret. Because key generation is a part of an encryption process, I said the encryption process must be secret.

(Secret Key generation algorithm -> Public known AES algorithm) = still a secret encyption approach.

I'm sorry i offended you with wikipedia, its there for others to review and not just you so that others can make an informed decisions based off of some information rather than just what an individual has to say. You may have alot of text books on this (and hey ... so do I) but it doesn't sound like you have real world experience implementing a process for a complete client side encryption to generate a unique identifier, which I have.

Your answers seem to sound text book with little experience because you said this one thing: "The method of generating the key does not have to be secret." Tell me then, how does the key remain secret if the key generation is know? Lets get detailed, please elaborate your process on how you would generate a unique system based key (computer configuration) and keep the key secret with your key generation process being known? Couldn't i just create a malware that runs the same key generation process because everything is handled client side?

Your statement that the key generation process can be known but that the key will remain secret is like saying, the key generation process is to add the the numbers 1 + 2 + 3 + 4 + 5 and the sum will be the key, but that the key will remain secret and no one can figure out that the key will be 15.

What confuses me more is that you said this: "All that matters is what you feed into the algorithm is secret and the algorithm output is sufficiently complex." I'm not sure if you worded your sentence wierd and i'm not understanding this correctly but... If you truly believe this then you may not clearly understand how encryption works. if you give me any ciphertext, encryption key, and algorithm, I will be able to decrypt it NO MATTER WHAT. If you're talking about an asymmetric encryption algorithm and not a symmetric algorithm... then there is a matter of another key which still needs to be secret anyway. Can you clarify what you meant?

[Pun]

I currently use TrueCrypt to encrypt important files with either AES or Serpent-Twofish-AES and the RIPEMD-160 hash algorithm. Would it be safe to assume that placing the destination folder in the POL Security Settings within a TrueCrypt virtual drive would be just as safe as placing it on removable media such as a flash drive? Would I need to keep the drive mounted during gameplay?

[Purrrfect]

I fail to see how saving the file to a removable drive will help very much. If you often bazaar, you'll end up leaving the drive connected a lot, and also after a while I'd guess most people will get tired of swapping the drive and eventually leave it in full time.

[netz]

Let me clarify because it sounds like you don't understand what i'm saying. An encryption process is an entire process of hiding information and part of that is the Key Generation. The key generation must be secret. The process of which the key is used to encrypted does not. But because a Unique Identifier for the system is generated with POL, this process is completely client side. That is why the process in which the key is generated must be secret. Because key generation is a part of an encryption process, I said the encryption process must be secret.

(Secret Key generation algorithm -> Public known AES algorithm) = still a secret encyption approach.

Quoting for emphasis.

To restate, the weakness in the current encryption scheme potentially lies in the generation of the private key. Additionally, you cannot passphrase it, like you can with SSH. We don't know if the unique system ID predictably maps to a single private key (doubtful, I'd think) or if there's some randomness attached to it. This is why you can specify the location of the key and place it on removable media, because if you can reliably generate a private key to decrypt the users' saved password file, the only defense is going to be to make the file inaccessible.

I currently use TrueCrypt to encrypt important files with either AES or Serpent-Twofish-AES and the RIPEMD-160 hash algorithm. Would it be safe to assume that placing the destination folder in the POL Security Settings within a TrueCrypt virtual drive would be just as safe as placing it on removable media such as a flash drive? Would I need to keep the drive mounted during gameplay?

For this case, this layer of security is potentially irrelevant. If anyone running as you can access your encrypted drive, why wouldn't the trojan be able to do it when POL goes to read the file?

Part of the problem with security on your average Windows desktop lies in the fact that virtually everyone at home (myself included) is running logged in as an Administrator. This gives trojans greater latitude in hiding themselves (there aren't that many places where they'd be permitted to install without obtaining Administrator-level privileges).

[cdgreg]

Alright, let me lay out my questions here and let me know if I'm missing anything since I'm trying my best to understand but am still a bit confused. Only I have access to my account, however I (and others) have access to the LS mules. If I am reading correctly, everytime someone successfully logs in from a different PC to the LS mules:

the saved information will be erased and the encryption key will become unusuable.

Now considering:

security settings are shared by all registered members.

should I assume that means the security settings for my main account have also been reset once an LS mule is logged in? So in summary basically every time someone logs onto LS mules I need to re-do my security settings? As annoying as it is, I really don't mind re-doing security settings every time I plan on logging in if that is what is necessary.

Would it also be possible to install ffxi on 2 different drives? Such as my primary C:\ and also an external HD and then only register mules to one location, and my main to another? Thus keeping my main's security settings intact even when ls mules are logged on?

Lastly, unless I missed something while keeping up with the smart.dll it was assumed smart.dll stole your PW from memory. Does that mean it could not have effected people who cut and pasted their PW from a notepad and only those who store it? Or once you log in is your PW stored in memory as long as you are logged in? Sorry for the annoying questions but if cutting and pasting my PW from a notepad on a flash drive I can take out as soon as I am done using it is the best option I will be glad to do that.