No announcement yet.

Password obfuscation

  • Filter
  • Time
  • Show
Clear All
new posts

  • Password obfuscation

    A little while back, here, we looked at splitting a password into two parts: A difficult, if not impossible, part to remember and written down and the other part memorable and committed to memory only.

    I moved on a little and looked at obfuscating the memorable part before adding it to the written part. It then occurred to me that if the obfuscation was good enough we could dispense with writing anything down. By "good enough" I mean generating a ciphertext password from a memorable plaintext password that is indistinguishable from one generated at random.

    With encryption/decryption we have Plaintext => Ciphertext => Plaintext. The Plaintext is secret. The Ciphertext is public as is the reversible method of encryption/decryption. We require that the Ciphertext is also secret and the method be irreversible.

    We have an irreversible function built in PB: RND. With each iterate there is discarded truncation making it impossible to reverse engineer. To produce the same Ciphertext password for a given Plaintext password we have to use the same seed for RND but I did not want to have to remember a seed for a given Plaintext password. The obvious solution is to generate a seed from the Plaintext password.

    One simple way to create such a seed is to calculate the CRC32 of the Plaintext password. Single precision is the preferred input for RANDOMIZE so the square root of the CRC32 is used. We have then:-

    Seed = Sqr( CRC32( Plaintext password ) )

    The Plaintext password is secret, so then is Seed.

    Plaintext is often transposed as part of an encryption process. A key is used to allow reversibility. We don't use a key and use a random shuffle as the transposition.

    In the following, Plaintext password means shuffled Plaintext password.

    The next part of the method is an adaptation of Vigenére's substitution cipher. This cipher is 400 hundred years old and is obsolete and insecure in its original form.

    Its simplest form is as follows
       A B C D E F G ...... X Y Z
    0  A B C D E F G ...... X Y Z
    1  B C D E F G H ...... Y Z A
    2  C D E F G H I ...... Z A B
    24 Y Z A B C D E ...... V W X
    25 Z A B C D E F ...... W X Y
    Each Plaintext character is read from the top row and the corresponding Ciphertext character is read from the row with a given left rotation/key in the first column. The '0' row is effectively a copy of the character set.

    For example, DAY and keys 2, 24, 25 encrypts to FYX. Note that repetitions in the Plaintext are not reflected in the Ciphertext.

    The keys used are secret to the sender and the recipient. We do not have a recipient and, as with Seed, we do not want to write anything down.

    We depart from the classical approach by initially shuffling the copy character set and we also shuffle the rotation rows. For the keys, the first character of the Plaintext password uses the first rotation row, whatever that is after the rotation row shuffle. The second character of the Plaintext password uses the second rotation row, and so on.

    The method can be described as follows:-
    Shuffle the Plaintext password.
    Shuffle the copy character set.
    Loop { Randomly rotate the copy character set.
           Read a character.
    There is a security enhancement which is optional: A seed file. Here, we browse to a file, to be kept secret, and its contents are added to the Plaintext password for calculating Seed. In this case we have

    Seed = Sqr( CRC32( Plaintext password || Seed file) )

    The implementation of a Seed file introduces an interesting twist. For differing passwords instead of actually using different Plaintext passwords we could use the same Plaintext password but use different Seed files. In effect, the Seed file is simply a second password and we can choose to fix one and vary the other. We have also come full circle with the Plaintext password being the memorable part and the Seed file being effectively the part written down.

    It is not thought that RND being only a 32 bit function, having then an entropy of 32 bits, is a weakness but to further frustrate an attack, if a Seed file is used RND is re-seeded using only the Seed file before the rotation rows are shuffled. This gives an entropy of 64 bits from 2^32 * 2^32.

    EDIT: I was writing these notes during development. The above paragraph is no longer true. Re-seeding is now done with the shuffled Plaintext password. If a Seed file is used it is appended to both the Plaintext password and the shuffled Plaintext password. So, a Seed file is no longer a requirement to have the increased entropy.

    Further edit: RND has been replaced by Mersenne Twister - see post #3. However, re-seeding is still done prior to shuffling the rotation rows.

    There is a school of thought which recommends avoiding character repetition in passwords and another which does not.

    One gauge to a password's strength is the NIST formula for randomly selected characters:-

    Entropy = log2(n^k) where n = character set length and k is the password length. This can be written as k*log2(n).

    The entropy of one character taken at random is then log2(n). In prohibiting that character from repetition the entropy of the next character taken at random is log2(n-1). In taking k characters the total entropy is:-
    Entropy (No repetition) = log2(n) + log2(n-1) + ... + log2(n-(k-1))
                            = log2(n*(n-1)* ... *(n-(k-1))
                            = log2(n!/(n-k)!)
    With n=94 and k=20 allowing repetitions gives 131.09 bits of entropy. Prohibiting repetition gives 127.95 bits. This is, roughly, a reduction of 3 bits. We would get the same reduction by dividing the character set by 8 (2^3), see below, or reducing the password length by about half a character. So, avoiding repetition reduces entropy.

    In general, I favour allowing repetitions but the application here, called PWO.exe, has an option to prevent repetitions - the default being non-selection.

    The power of password length over character set complexity is illustrated by considering a single character password and a multiple, m, of the character set length giving log2(n*m) = log2(n) + log2(m) which simplifies to log2(n) + 1 when m=2. So, doubling the complexity, for example, gives an increase of one bit per password character.

    We get one bit of entropy per character for a character set of just two characters, 4.7 bits for 26 characters and 5.7 bits for 52 characters. In the latter case we can increase the total entropy by 5.7 bits just by adding one more character to the password.

    Clearly, the total entropy is much more sensitive to password length than it is to character set complexity. So, even with a restrictive character set we could have a strong password provided it was sufficiently long. An alphanumeric set, for example, of 62 characters gives 5.95 bits per character. A strong password, exceeding 128 bits, can be got provided its length exceeded 21 characters ( chosen at random ); which, of course, may not be allowed in some cases.

    Here is the form which is top down designed.

    I have found that choosing the character set is easier done by selecting all of the subsets and then deselect those which cannot be used and then add additional characters in the custom character set text box, if any, that may be allowed.

    If the custom character set is selected any entries cannot be repeated within its text box and nor can any entries repeat any available in any chosen subset above. 'Violations' are reported and the first, if more than one, character is highlighted.

    The entries in the Plaintext password text box must, of course, only be those available in the chosen character set and offending entries are highlighted here too.

    The Ciphertext box is unusual in that it does not obscure characters. This is a 'playing around' mode. In use the command switch '/secret' will see the Ciphertext text box removed. On clicking the Obfuscate button the Ciphertext password is placed onto the Clipboard for pasting to whatever requires the password. The Clipboard is reset on closing the application. If you have a Clipboard manager then a history will be kept and you may need to attend to that manually.

    In 'playing around' mode I found that the application is better to be Topmost and in '/secret' mode it was found to be better not to be Topmost. Topmost is determined automatically.

    The password text boxes use 10 point Courier to aid readability.

    There is a status bar which details the password length, entropy (dependent upon allowing repetitions or not) and time taken; including reading a Seed file, if used. The entropy is calculated using the NIST formula assuming that my contention of the Ciphertext password being indistinguishable from one taken at random is true.

    You may be very organised with your passwords and use something like TrueCrypt. However, how do you open TrueCrypt? TrueCrypt allows all of PWO's character subsets except the Alr Gr set (áéíóú) and passwords up to 64 characters long are allowed.

    How about this 57 character password?

    K=~jJYe6P(W)9*gzm_t"[email protected];|O~z`/MnbL^D0\nd_rS$1lK2u9o1Y$

    With repetitions allowed the entropy is 374.5 bits. A brute force attack on the Ciphertext password will, on average, succeed at 2^(374.5/2) attempts. That is greater than 10^56. There is not a computer on the planet fast enough to get anyway near that and that may the case for some time to come.

    The Plaintext password is:-

    The time has come the walrus said to talk of many things.

    There is an issue which I have not been able to resolve. '&' is available in the "`! ... .?" character set but it does not get displayed in a control's label. Obviously, this has something to do with hot-keys. How can I display '&'.
    Attached Files
    Last edited by David Roberts; 13 Aug 2009, 07:52 PM.

  • #2
    > It is not thought that RND being only a 32 bit function, having then an entropy of 32 bits, is a weakness ...

    I have received a Private Message from one of the forum's crypto gurus reckoning that using PB's RND function is a "fundamental flaw" and "it is possibly the weakest link in your code".

    OK. Don't use PWO as is.

    I'll be back.


    • #3
      I could not replace RND with a cryptographically secure algorithm as, by definition, they are unpredictable and we would, therefore, not get the same Ciphertext password for a given Plaintext password.

      It was recommended that I use Greg Turgeon's Mersenne Twister - so I did.

      Version 1.1 has been uploaded in post #1.

      This version does not clear the clipboard if we are not in '/secret' mode - that was not intended but got coded that way.

      So, who has been advising me in the wings? I hope he does not mind mentioning him - Wayne Diamond. Thanks Wayne.

      Greg has always OK'd my using his forum code and Greg has been credited in PWO's property sheet.

      I know PWO's icon is diabolical - I'll try and do better.
      Last edited by David Roberts; 10 Aug 2009, 08:02 PM.


      • #4
        BTW, it is worth noting that the smaller the character set used and the longer the Plaintext password the more likely repetitions are so don't be surprised at their frequency.

        Here is a password generator.

        For 20 passwords of length 20 characters, ticking all boxes except 'No similar characters:' I got:-

        [email protected]
        5!Usoumoad*[email protected]&_8
        [email protected]
        CoeJL6Rlu&[email protected]!
        d$&[email protected]=7H8A6oej!3

        Look at the 10th row - 'a' is repeated three times. This is not a problem.


        • #5
          In post #1 there are a couple of red edits.

          The first one is a blunder. I was on the right track with re-seeding via the Seed file. If we shuffle the Plaintext password we are not introducing any new information so we do not get double the entropy. If we can shuffle then so can an attacker. However, with two independent seeds then we do double the entropy.

          Right, it is time to get mean.

          Out goes CRC32 and in comes MD5. This hash algorithm has an output of 128 bits.

          We have three shuffle steps: Plaintext, Character set and Rotations.

          For the first step we take the first 32 bits of the MD5 hash to seed Mersenne Twister (MT).

          Before the second step we break the sequence and re-seed MT with the second 32 bits of the hash.

          Before the third step we break the sequence yet again and re-seed MT with the third 32 bits of the hash.

          An attacker has to get past three doors and each one costs 32 bits.

          We have then a 96 bit cruncher.

          A 20 character password on my machine takes about 0.16ms to complete ie about 6250ps.

          The IBM RoadRunner ticks over at 1.105 petaflops. An Intel Core i7 965 XE ticks over at 70Gflops.

          The RoadRunner is then about 15786 times faster than the Intel.

          The Intel is not 100 times faster than my machine but suppose it was then the RoadRunner would be about 1,600,000 faster than my machine.

          My 6250ps would become 1x10^10ps. ...... [1]

          With a 96 bit cruncher an attack would be successful, on average, after 2^95 attempts. ...... [2]

          [1] + [2] => 1.25x10^11 years.

          That is about 8 to 10 times the age of the universe as I write this.

          We are OK. Do we have a smilie for a straight face?

          So, version 1.2 implements MD5 and Mersenne Twister compared with version 1.0 with CRC32 and RND.

          Version 1.2 uploaded in post #1.

          Another guesstimate.

          From here:
          Currently, estimates that cracking a 72-bit key using current hardware will take about 403,784.9 days or 1,105.5 years.
          Dedicated hardware note.

          So, for 96 bit we have 2^24 x 1105.5 => 1 to 2 times the age of the universe.

          We are still OK.

          Final note:

          Aim for 80+ bits for your Ciphertext entropy. NIST recommendation. That gives 283,000 years for a brute force attack with current hardware. You probably won't need to change it - ever.
          Last edited by David Roberts; 11 Aug 2009, 01:56 PM. Reason: Another guesstimate.


          • #6
            > I know PWO's icon is diabolical - I'll try and do better.

            It now has a posh icon.


            • #7
              There is an issue which I have not been able to resolve. '&' is available in the "`! ... .?" character set but it does not get displayed in a control's label. Obviously, this has something to do with hot-keys. How can I display '&'.
              To include an ampersand in a caption, use two ampersands.
              Seems to be true for text associated with any control.

              I scoured the Internet and ended up at PB Forms On-line Help.

              I'll get to including it in the form one of these days.


              • #8
                Hi David,

                Check out the SS_NOPREFIX window style for static controls (labels). From MSDN:

                Prevents interpretation of any ampersand (&) characters in the control's text as accelerator prefix characters. These are displayed with the ampersand removed and the next character in the string underlined. This static control style may be included with any of the defined static controls. You can combine SS_NOPREFIX with other styles. This can be useful when filenames or other strings that may contain an ampersand (&) must be displayed in a static control in a dialog box.



                • #9
                  Thanks Peter. CheckBoxs aren't static controls. I tried it but to no avail and it is not mentioned in PB Forms Help. It is with regard to Labels and it worked with them.

                  This is what I'm using for the special character set:-

                  Control Add CheckBox, hDlg, %Special, "` !" + $Dq + "$ % ^ && * _ + - = : ; @ ' ~ # | \ / , . ?", 18, 58, 148, 10, , , Call CBF_Charsels

                  With the double & entry only one gets displayed.


                  • #10
                    '&' is now plainly visible. It has always been available - just not visible.

                    I have also taken the opportunity to correct an oversight.

                    In /secret mode the Ciphertext text box is removed and that has been the case from the outset.

                    In /secret mode the Plaintext password should be obscured - it may not be the password actually used but it is a password, nonetheless.

                    I shall not be tinkering with the character sets or the obfuscation code again so, unless you or I spot something untoward, then it is now carved in stone.

                    Version 1.2.1 uploaded in post #1.

                    Before I leave this topic just a few more figures.

                    From the previous post:-
                    My 6250ps would become 1x10^10ps. ...... [1]

                    With a 96 bit cruncher an attack would be successful, on average, after 2^95 attempts. ...... [2]

                    [1] + [2] => 1.25x10^11 years.
                    The maths is much easier than with hashing algorithms.

                    Suppose that an attack was successful after 2^72 attempts. ...... [3]

                    [1] + [3] => 14,975 years.

                    However, the chance of that success is 2^(96 - 72) = 2^24 => 16,777,215 to 1 against.

                    So, an attacker can break 96 bits in just less than 15,000 years provided, on average, they are a little luckier than someone winning the UK lottery with just one ticket.

                    This is, of course, assuming that the Intel is 100 times faster than my machine. If it were only 10 times faster, more like it and still an over estimate, that 15,000 becomes 150,000 years.

                    150,000 years and taking more luck than winning the UK lottery.

                    Still mind boggling but closer to home than talking about the age of the universe.

                    We can get 95.27 bits with alphanumeric (upper and lower case) and 16 characters.

                    I hadn't realised it but we need a different mindset than with hashing algorithms.

                    With MD5, a 128 bit algorithm, there is a 63% chance that a collision will occur after 2^64 file/message comparisons. 64 bit is why NIST rejected MD5. After all, DES was put out to grass at 56 bit. Their starting point for hashing algorithms was set by SHA1 at 160 bit giving a 63% collision chance at 2^80 comparisons. There is that 80 again.

                    Just to end on a bang:

                    alphanumeric (upper and lower case) and 16 characters has 62^16 possible passswords

                    that is, 47,672,401,706,823,533,450,263,330,816
                    Last edited by David Roberts; 13 Aug 2009, 08:15 PM.


                    • #11
                      Hi David,
                      Thanks Peter. CheckBoxs aren't static controls. I tried it but to no avail and it is not mentioned in PB Forms Help. It is with regard to Labels and it worked with them.
                      It appears that adding this style to checkboxes only works when you have Windows XP themes enabled and include a manifest in your program. Presumably it's only something that's included in a later version of the control.

                      See attached pic of a FireFly app that shows it. Both checkboxes have the same text, but the lower one has the %SS_NOPREFIX style added.


                      Attached Files


                      • #12
                        Blimey! Thanks, Pete.

                        What I know about XP Themes can be put on the back of a postage stamp. I throttled mine shortly after getting XP and have never looked forward since.

                        I didn't even like the default Classic à la '98 - I found the button's highlight/shadow a little sudden, redesigning them as in the opening post.


                        • #13
                          I have introduced another PRNG, namely George Marsaglia's multiply-with-carry (MWC). In fact, it is a stripped down version of RND2 concerning itself with ranges only ie Rnd2(i,j). If you haven't heard of Rnd2 it was originally put forward by myself on these forums and greatly improved by John Gleason and Gary Ramey with me contributing in the wake of their assembler expertise. MWC is very fast and has a good distribution.

                          It is so fast I had to slow it down to maintain a workload reaching the Ciphertext password in the event of a Plaintext password attack. This was easily done by simply increasing the random shuffles from one pass to many passes.

                          Since the power of our machines vary it was decided to allow a user to input the number of shuffle loops to execute. The time taken to reach the Ciphertext password is only partly due to the algorithm used - the rest is in checking the validity of the input. The status bar time only ever showed the algorithm time as this is the workload an attacker would be faced with. I figure that between 50ms to 250ms would be acceptable so it is simply a matter of trial to get a shuffle loop to use. Of course, it is the power of the attackers machine which is important so we shouldn't accept too fast a calculation on our own machine/s.

                          Any pertubation of the shuffle loop will see a totally different Ciphertext password. We could use something like 23691.

                          Effectively, our poor old attacker now has a PIN number to contend with.
                          I shall not be tinkering with the character sets or the obfuscation code again so, unless you or I spot something untoward, then it is now carved in stone.
                          The Mersenne Twister code is still in there and can be got at by the switch /mt. The Shuffle loop box should either be empty or have a value of 1, along with the /mt switch, to produce the same output as version 1.2.1.

                          In /Secret mode entries to the Shuffle loop box will be obscured.

                          It may be a case of early days but the chance of repetitions appears to be less with MWC.

                          I have added another switch to allow pre-selection of the characters sets. The character sets are numbered left to right and then down. So, for example, the numeric set is set 3. Space, for example, is set 7.

                          To pre-select an alpha-numeric set we would use /Sel: 1,2,3.

                          All swithches are case insensitive and may be entered in any order, spaces may be used as desired and the pre-selections, if any, may be in any order as well.

                          This is how the new form looks.

                          Version 1.3 uploaded.
                          Attached Files
                          Last edited by David Roberts; 2 Sep 2009, 06:57 AM. Reason: comtend?


                          • #14
                            I sometimes think that much of my code is driven by an innate bone-idleness.

                            Anyway, I've just come across a rather nifty free password manager here. KeyWallet, as with many password managers, allows all of the character sets of PWO.exe with the exception of the Alr Gr set.

                            PWOLite.exe is, yep, a light version of PWO.exe with the following differences.

                            All of PWO's character sets are pre-selected except Alt Gr, Space and the Custom character set.
                            Secret mode is the only mode.
                            The optional seed file is not available.
                            Prohibit repetition is not available.

                            This is what it looks like in action providing a password for KeyWallet.

                            As you can see we don't have much work to do: Enter the Plaintext password and the Pin Number (aka Shuffle loops) and then click on Obfuscate. We now simply Paste into the target and close PWOLite.

                            Mersenne Twister is still available via the /mt switch.

                            I don't have a rational explanation for not including Space - I simply prefer a password as opposed a passphrase.

                            If you want Space then add the switch /Space.

                            What I would like is to get rid of the Obfuscate button and have a key icon to drag and drop onto the target. Shell data transfer can do that but that is so far above my head that I cannot see it even with a pair of binoculars. I have seen it done - KeyWallet does it.

                            Version 1.0 uploaded
                            Attached Files
                            Last edited by David Roberts; 11 Sep 2009, 06:28 PM.


                            • #15
                              You might want to read Applied Cryptography by Bruce Schneier. It's a bit dated, by this point, but it will give you a grand overview of the field of cryptography.

                              You might want to be clear on the points that security by obscurity simply doesn't work. Nor does any encryption scheme you thought up for yourself. There are serious maths involved in cryptography, and there's no point in creating your own unless you're planning to divert a few clueless goobers who were idly wondering if they might run off with your bicycle.

                              Lord knows, that's not pointless, but it's a minor deterrent, not genuine security.


                              • #16

                                You made me grin. I'm 58 (yesterday) and goobers is a word of my childhood. Can't say that I've heard it / seen it in some time.

                                Also, it would be an interesting statistic to see how many data thieves are of the goober variety, and how many might be cashews! For that matter, I'd like to see statistics on what percentage of data theft comes from physical theft (presumably more of the goober variety thiefs) and what percentage comes from an online/network based theft (presumably closer to the cashew types). That would help clarify whether trivial security has any practical benefits.


                                • #17
                                  Tom, if you do a search of this thread using 'cryptography' it does not appear until your post.

                                  I make no cryptographic claims whatsoever.

                                  Encryption is bi-directional - I definitely did not want that which is why I favour MWC.

                                  Hashing is about degrees of uniqueness. I don't want degrees of uniqueness - I want uniqueness which is why a PRNG is used rather than a CPRNG.

                                  I'm not talking about cryptography.

                                  All I am doing is to take a memorable password which a cryptanalyst may be able to break using a dictionary attack or a statistical attack, for example, and increase its entropy by obfuscation to the extent that only a brute force attack is left as a viable option.

                                  For example:

                                  Plaintext: Try and crack me if you can, Pin number: 48751


                                  Ciphertext: H'kz^AS0eH2ei+3;O<a%^~5oN3i using all character sets except Alt Gr.

                                  My contention is that the Ciphertext is as good as random selection and, if so, the above has an entropy of 177.39 bits which is not going to be cracked by any machine on this planet for a very long time to come.

                                  The point of the exercise is in using a decidedly unmemorable password without having to write it down. The memorable password and the Pin number are not written down either, obviously.

                                  So, we end up using H'kz^AS0eH2ei+3;O<a%^~5oN3i without it having to be written down.

                                  A reverse brute force attack would set about the Plaintext. Here, of course, the attacker would have to use the method employed and have to wait until the crunching was completed because we are not using the Plaintext password - we are using the Ciphertext password. If access was available to an IBM Roadrunner then a lot more trials can be done than on my machine which took 278.01ms - that is about 4 trials per second. Even an IBM Roadrunner is not gong to increase that four trials per second to anything like what an attacker needs. This is, of course, assuming that the attacker knows the Pin number, which can be any value between 1 and 999999, but that isn't known either.

                                  So, neither a Plaintext nor a Ciphertext attack is viable.

                                  If an attacker used thumb screws on me to divulge the password entered into KeyWallet in post #14 above we would have a problem because I don't know what it is - KeyWallet obscured it. I would have to give the attacker PWOLite, the Plaintext password and the Pin number. On the other hand if an attacker broke into my home and stole my machine they would not live long enough to crack a, contended, randomly chosen 26 character password.

                                  I am not talking cryptography - I'm talking uncrackable passwords which don't have to be written down. That is all it says on the tin.


                                  • #18
                                    OOPS! I forgot to reinstate %ES_AUTOHSCROLL when in secret mode. It makes no odds when using a password of 26 or less characters but if we use TrueCrypt, for example, and want to push the boat out beyond 26 characters then without %ES_AUTOHSCROLL we cannot. Corrected in both PWO (secret mode) and PWOLite. DDT is all very well holding our hands but we still have to keep our eyes open.

                                    I have pulled the Pin number (aka Shuffle loops) into the Seed calculation so that we now have

                                    Plaintext password [ || Pin number ] [ || Seed file ] where [] is the 'optional' convention.

                                    Previously, to maintain compatibility with version 1.2.1 we had to either have an empty Pin number field or '1'. Actually, '0' would have been OK as well. Now, of course, to maintain compatibility, the Pin number field must be empty otherwise anything in there will get concatenated.

                                    I have also tweaked PWOLite's form so that it is a little more compact.

                                    I wish ideas came in a bit faster - must be senile decay creeping up on me. I've got arthritis coming in and out and I used to be able to spot a mini-skirt half a mile away - now, if I'm not within 200 yards I miss 'em. Oh, dear.

                                    To keep life simple PWO V 1.3.1 and PWOLite V 1.0.1 are uploaded here in a zipped folder PWO.

                                    I've had some thought on my contention.

                                    If we have a non-random variable input and subject it to a pseudo-random function then the output is a pseudo-random variable.

                                    That is obvious.

                                    If we use the non-random variable as our Plaintext then the pseudo-random variable is our Ciphertext.

                                    It follows that Entropy(Plaintext) <= Entropy(Ciphertext). If we define a password taken at random as Randomtext then my contention is

                                    Entropy(Plaintext) <= Entropy(Ciphertext) = Entropy(Randomtext)

                                    If the contention is false then we must have

                                    Entropy(Plaintext) <= Entropy(Ciphertext) < Entropy(Randomtext)

                                    In this case the entropy figures calculated in PWO would be upper bounds.

                                    I would then contend that Entropy(Ciphertext) is very close to Entropy(Randomtext).

                                    Notice that the above is a cryptography free zone.
                                    Attached Files


                                    • #19
                                      I was reading a discussion the other day about password masking. One guy said hat it had been around a long time so get used to it and if you make mistakes then learn how to type. I suspect that he has a monochromatic view of most things. Most, if not all, password managers mask entry passwords whether we like it or not.

                                      I don't think that we have a case of for or against but a case of for or not for. There are many reasonable arguments for and I'd probably accept all of them. However, if you are in an environment where none of the arguments for hold and masking is a tad irritating then you'd probably welcome no masking.

                                      It may seem a bit of a contradiction to have no masking with PWO in secret mode but masking is only a part - the Ciphertext output is hidden as well.

                                      No masking is achieved with the switch /MaskOff, case insensitive as usual, for both PWO and PWOLite.

                                      I cannot edit the last post so a zipped PWO folder is uploaded here.
                                      Attached Files