Prev: A link on North Korean home-grwon OS
Next: If we could factor large numbers quickly, how exactly does everything break?
From: WTShaw on 17 Apr 2010 03:21
On Apr 16, 9:29 am, bmearns <mearn...(a)gmail.com> wrote:

>
> You're just arguing for my point, which is that you were preaching
> security by obscurity (when you said "it is right to encourage private
> generation of complex keys"), but you're also publishing a key-
> generation algorithm, so it's not obscure. Like you said, you can't
> have it both ways, so which will it be?
>
One of many generation means is not so important but what it does is.
So, figure out how you can reverse engineer some seed words. Oh,
forgot to tell you that you can change those words mid generation as
long as you don' reset. The permission button to allow another
scramble is protection against glitches or multiple unintentional
processing.
> > Random is good as all keys can be so.
>
> Look, I'm guessing that English isn't your native language, but if you
> intend to have a discussion, you're going to have to work on
> communicating more clearly.
>
> > However, your qualifying a key
> > as one you allow is not random at all but is descriptive.
>
> At what point do you think I defined a set of allowed keys?
>
By wanting to force selection of ranked permutations, or any way that
is likely to be more error prone than what I have done.
>
> > > I'm quite comfortable with the mathematics of any rational base. But I
> > > don't see what that has to do with the current discussion.
>
> > > -Brian
>
> > Bases differ as to characteristics.  I prefer those with more native
> > promise that other.  Bad bases can make otherwise good algorithms
> > produce less than optimum results.
>
> Then give an example. I'm tired of hearing this bullshit. The only
> thing that changes between bases is how effectively you can represent
> them in other bases.
>
> -Brian

Hang in there, growth can be painful. BTW, I have another easier to
read version of that app that I'll put up in a few minutes if it is
allowed. You're going to love Kulu and Chambal when I'm ready with
those, beautifying them at present.
From: bmearns on 20 Apr 2010 09:01
On Apr 17, 3:07 am, WTShaw <lure...(a)gmail.com> wrote:
> On Apr 16, 9:29 am, bmearns <mearn...(a)gmail.com> wrote:
>
>
>
> > That is so beyond irrelevant I'm having trouble coming up with a
> > snarky response. Is your technique that weakens keys supposed to be
> > the ride?
> > How about this: I'd rather walk than ride in a car that gives away my
> > secrets.
>
> Keys are most weakened when they are written down and taped to a
> computer.

Not universally true, but a reasonably fair statement. But what does
it have to do with anything?


>
>
>
> > Okay, we'll start with the theory behind that. You're right, if the
> > initial permutation could be changed, that would add another
> > log_2(65!) bits of information to the input secret. If the alphabet
> > could be changed, it would increase security enormously. However, at
> > that point its actually pointless: the permutation of 65 elements can
> > only contain a maximum entropy of log_2(65!) bits, so trying to stuff
> > more than that into the seed doesn't make sense.
>
> The big question is how much cipher text do you need to solve to a
> conclusive message?

Given that this is just a monoalphabetic substitution cipher with an
alphabet of only 64 characters, I'm guessing not that much. But I'll
see if I can run some tests and get back to you.


>
>
>
> > I will concede that I largely overlooked the possibility of changing
> > the initial permutation. Now let me explain why: the JavaScript/HTML
> > you posted--which is the only thing we have to go by since you didn't
> > bother actually explaining your algorithm--does not allow the initial
> > permutation, let alone the alphabet, to be changed by the user. You
> > may have intended for it to be possible, you did after all post it in
> > an editable field. However, the set that the scramble is actually
> > performed on comes from form.set65$.value, where "set65$" is a hidden
> > field that the user can't edit. Thus, you can change the permutation
> > given there all you want, but it won't actually effect the result.
>
> Java Script is open sourced.  Many like us can change it anyway we
> want.  To see that it can't be by many tells us that they need
> keepers, not us.

Revealing your ignorance as usual. To say JavaScript is open source is
meaningless. JavaScript is not code, it is a standard. There are many
different implementations, some of which are open sourced. However,
given the clumsy nature of the JavaScript code you provided, it's
laughable to suggest that you actually modified an open source
implementation of JavaScript.

If you're referring to your particular JavaScript code as being open
source, then you're at odds with yourself. On the one hand, you're
boasting about a feature whereby users can provide their own alphabet
in order to provide any sort of reasonable security, and on the other
you're saying they have to modify the source code to do it? That's
absurd, given that it would be trivial to accept the user's alphabet
directly in the web page.

Just admit that this was a bug. You provided an editable field that,
by all appearances, allows the user to provide a custom alphabet, and
yet they are not actually able to. It's okay, all software has bugs.
Your inability to either identify it as a bug or at least admit that
it is a bug when someone else identifies it just goes to show that
your cockiness far exceeds your programming ability.


>
>
>
> > For instance, I started with the defaults: an initial permutation of
> > "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/= ",
> > a seed of "basesixtyfivecipher", and an "adder" of 3. Upon scrambling,
> > the output was "4IMQVghTDP9ANBLlCXbfo3ZO=czq1Ji+S2vE0uR5pme/
> > dwrK6jGFsx7HYUnya8Wtk". I reset the form, used the default seed and
> > adder, and put a different initial permutation in the field:
> > "opqrsDEFSfghijktuvwxGHIJTUVW6789+/=XYZayz012bcdeKLMABClmnNOPQR345".
> > The resulting output: "4IMQVghTDP9ANBLlCXbfo3ZO=czq1Ji+S2vE0uR5pme/
> > dwrK6jGFsx7HYUnya8Wtk", exactly the same as the first time. So not
> > only are you blocking this particular avenue of increasing security,
> > but now the hypothetical users who use this system will have an
> > incorrect result, because they think the scramble and resulting
> > encoding come from the permutation they gave. If they use this as a
> > shared key with someone using a correct implementation, they won't be
> > able to communicate.
>
> Knowing Java Script as you do, look for a hidden field that is the
> source for the displayed perm. For those many, entering an improper
> string directly would be more of a problem, just like you tried.
>
>

No, if your form had worked, then the strings I entered would have
worked perfectly well. And it would be extraordinarily easy to check a
user's input to make sure it is a valid 65 character alphabet. But
you're basically admitting that this is an advanced feature that
requires the user to hack the JavaScript in order to use it. And yet
the security of the algorithm all but rests on the ability to do this.
So in essence, they can write the program themselves, or they can use
your implementation and suffer from a lack of security.

-Brian

From: bmearns on 20 Apr 2010 09:13
On Apr 17, 3:21 am, WTShaw <lure...(a)gmail.com> wrote:
> On Apr 16, 9:29 am, bmearns <mearn...(a)gmail.com> wrote:
>
>
>
> > You're just arguing for my point, which is that you were preaching
> > security by obscurity (when you said "it is right to encourage private
> > generation of complex keys"), but you're also publishing a key-
> > generation algorithm, so it's not obscure. Like you said, you can't
> > have it both ways, so which will it be?
>
> One of many generation means is not so important but what it does is.

Once again, please try to communicate better. The above "sentence"
doesn't make any sense, and the meaning is completely undecipherable.


[snip]
> > > However, your qualifying a key
> > > as one you allow is not random at all but is descriptive.
>
> > At what point do you think I defined a set of allowed keys?
>
> By wanting to force selection of ranked permutations, or any way that
> is likely to be more error prone than what I have done.

That's idiotic. Choosing amongst all possible permutations means
choosing amongst all possible values, it in no way limits the number
of selections. My point was only that there is already a standard way
to derive a permutation from an input value (by using factoradic
number system), instead of using the non-standard and un-specified
scrambling algorithm that you invented off the top of your head.



> > > > I'm quite comfortable with the mathematics of any rational base. But I
> > > > don't see what that has to do with the current discussion.
>
> > > > -Brian
>
> > > Bases differ as to characteristics.  I prefer those with more native
> > > promise that other.  Bad bases can make otherwise good algorithms
> > > produce less than optimum results.
>
> > Then give an example. I'm tired of hearing this bullshit. The only
> > thing that changes between bases is how effectively you can represent
> > them in other bases.
>
> > -Brian
>
> Hang in there, growth can be painful.

Your condescension knows no bounds.

But I don't mind, because by now it is obvious to everyone that your
arrogance is either a grand delusion, or (most likely) a shallow fraud
to cover your own insecurities.


> BTW, I have another easier to
> read version of that app that I'll put up in a few minutes if it is
> allowed.  You're going to love Kulu and Chambal when I'm ready with
> those, beautifying them at present.

Can't wait.

-Brian

From: WTShaw on 21 Apr 2010 02:01
On Apr 20, 8:13 am, bmearns <mearn...(a)gmail.com> wrote:
> On Apr 17, 3:21 am, WTShaw <lure...(a)gmail.com> wrote:
>
> > On Apr 16, 9:29 am, bmearns <mearn...(a)gmail.com> wrote:
>
> > > You're just arguing for my point, which is that you were preaching
> > > security by obscurity (when you said "it is right to encourage private
> > > generation of complex keys"), but you're also publishing a key-
> > > generation algorithm, so it's not obscure. Like you said, you can't
> > > have it both ways, so which will it be?
>
> > One of many generation means is not so important but what it does is.

As the saying goes, there are many ways to skin a cat. So it is with
key generation. Important is the idea of key generation in so many
ways that no particular one is required.
>
> Once again, please try to communicate better. The above "sentence"
> doesn't make any sense, and the meaning is completely undecipherable.
>
> [snip]
>
> > > > However, your qualifying a key
> > > > as one you allow is not random at all but is descriptive.
>
> > > At what point do you think I defined a set of allowed keys?
>
> > By wanting to force selection of ranked permutations, or any way that
> > is likely to be more error prone than what I have done.
>
> That's idiotic. Choosing amongst all possible permutations means
> choosing amongst all possible values, it in no way limits the number
> of selections. My point was only that there is already a standard way
> to derive a permutation from an input value (by using factoradic
> number system), instead of using the non-standard and un-specified
> scrambling algorithm that you invented off the top of your head.

All permutations are available anyway to anyone. Having a standard
way is a mean of guaranteeing prejudice by omission. What is important
about keys, the only thing that are to the algorithm, is that a key
can be properly interfaced the algorithm. Subjectively are that it is
easily remembered and used, and that no such advantages are granted to
anyone else regarding you key. Anyway, why be afraid of the
competition if you think the idea is so bad even though it isn't?
>
>
>
> > > > > I'm quite comfortable with the mathematics of any rational base. But I
> > > > > don't see what that has to do with the current discussion.
>
> > > > > -Brian
>
> > > > Bases differ as to characteristics.  I prefer those with more native
> > > > promise that other.  Bad bases can make otherwise good algorithms
> > > > produce less than optimum results.
>
> > > Then give an example. I'm tired of hearing this bullshit. The only
> > > thing that changes between bases is how effectively you can represent
> > > them in other bases.
>
> > > -Brian
>
> > Hang in there, growth can be painful.
>
> Your condescension knows no bounds.

Thanks.
>
> But I don't mind, because by now it is obvious to everyone that your
> arrogance is either a grand delusion, or (most likely) a shallow fraud
> to cover your own insecurities.

During the last three days, I did some of what you would otherwise
consider impossible, put some promises and suggestions including some
of yours into practice. The result is beautiful, an oracle-like
bootstrap Genie that seemingly does it all, and yes it accepts
specifically formatted other algorithms in combination with it as
systems.
>
> > BTW, I have another easier to
> > read version of that app that I'll put up in a few minutes if it is
> > allowed.  You're going to love Kulu and Chambal when I'm ready with
> > those, beautifying them at present.
>
> Can't wait.
>
> -Brian
OK, I'm ready. The first clues are in the names above. Let's see for
starters if you can easily discern the importance of those
names...Hint: Numbers are important.

Prepare yourself for Kulu Pizza, Chambal Pizza, and a demure and
tantalizing member of the extensive class, BLT Pizza. Pleased be
amused, but honestly use Google and try with the other two. The
answers mean more if you have a certain thrill of discovery.
From: WTShaw on 21 Apr 2010 02:16
On Apr 20, 8:01 am, bmearns <mearn...(a)gmail.com> wrote:
> On Apr 17, 3:07 am, WTShaw <lure...(a)gmail.com> wrote:
>
> > On Apr 16, 9:29 am, bmearns <mearn...(a)gmail.com> wrote:
>
> > > That is so beyond irrelevant I'm having trouble coming up with a
> > > snarky response. Is your technique that weakens keys supposed to be
> > > the ride?
> > > How about this: I'd rather walk than ride in a car that gives away my
> > > secrets.
>
> > Keys are most weakened when they are written down and taped to a
> > computer.
>
> Not universally true, but a reasonably fair statement. But what does
> it have to do with anything?
>
Your system should not lead a poor user into bad practices; there are
enough of them already.

> > > Okay, we'll start with the theory behind that. You're right, if the
> > > initial permutation could be changed, that would add another
> > > log_2(65!) bits of information to the input secret. If the alphabet
> > > could be changed, it would increase security enormously. However, at
> > > that point its actually pointless: the permutation of 65 elements can
> > > only contain a maximum entropy of log_2(65!) bits, so trying to stuff
> > > more than that into the seed doesn't make sense.
>
> > The big question is how much cipher text do you need to solve to a
> > conclusive message?
>
> Given that this is just a monoalphabetic substitution cipher with an
> alphabet of only 64 characters, I'm guessing not that much. But I'll
> see if I can run some tests and get back to you.
>
It perhaps was too easy for me but there is a certain data mixing
already i the coder. That might be easily changed to something a
little more advanced.
>
> > > I will concede that I largely overlooked the possibility of changing
> > > the initial permutation. Now let me explain why: the JavaScript/HTML
> > > you posted--which is the only thing we have to go by since you didn't
> > > bother actually explaining your algorithm--does not allow the initial
> > > permutation, let alone the alphabet, to be changed by the user. You
> > > may have intended for it to be possible, you did after all post it in
> > > an editable field. However, the set that the scramble is actually
> > > performed on comes from form.set65$.value, where "set65$" is a hidden
> > > field that the user can't edit. Thus, you can change the permutation
> > > given there all you want, but it won't actually effect the result.
>
> > Java Script is open sourced.  Many like us can change it anyway we
> > want.  To see that it can't be by many tells us that they need
> > keepers, not us.
>
> Revealing your ignorance as usual. To say JavaScript is open source is
> meaningless. JavaScript is not code, it is a standard. There are many
> different implementations, some of which are open sourced. However,
> given the clumsy nature of the JavaScript code you provided, it's
> laughable to suggest that you actually modified an open source
> implementation of JavaScript.

The standard is that it can be done open sourced. You don't see me
asking someones computer to crawl like a wounded animal to a distant
website for my pages to work.
>
> If you're referring to your particular JavaScript code as being open
> source, then you're at odds with yourself. On the one hand, you're
> boasting about a feature whereby users can provide their own alphabet
> in order to provide any sort of reasonable security, and on the other
> you're saying they have to modify the source code to do it? That's
> absurd, given that it would be trivial to accept the user's alphabet
> directly in the web page.

Remember at the fair, you have to be "this tall" to ride. Some need
to be dissuaded. Since the code is available, anyone qualified can
add features as possible improvements; try it.
>
> Just admit that this was a bug. You provided an editable field that,
> by all appearances, allows the user to provide a custom alphabet, and
> yet they are not actually able to. It's okay, all software has bugs.
> Your inability to either identify it as a bug or at least admit that
> it is a bug when someone else identifies it just goes to show that
> your cockiness far exceeds your programming ability.
>
There are limitations to the available language, and I don't demand
such changes, but including on the face and in the helps notes on such
things might help.
>
> > > For instance, I started with the defaults: an initial permutation of
> > > "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/= ",
> > > a seed of "basesixtyfivecipher", and an "adder" of 3. Upon scrambling,
> > > the output was "4IMQVghTDP9ANBLlCXbfo3ZO=czq1Ji+S2vE0uR5pme/
> > > dwrK6jGFsx7HYUnya8Wtk". I reset the form, used the default seed and
> > > adder, and put a different initial permutation in the field:
> > > "opqrsDEFSfghijktuvwxGHIJTUVW6789+/=XYZayz012bcdeKLMABClmnNOPQR345"..
> > > The resulting output: "4IMQVghTDP9ANBLlCXbfo3ZO=czq1Ji+S2vE0uR5pme/
> > > dwrK6jGFsx7HYUnya8Wtk", exactly the same as the first time. So not
> > > only are you blocking this particular avenue of increasing security,
> > > but now the hypothetical users who use this system will have an
> > > incorrect result, because they think the scramble and resulting
> > > encoding come from the permutation they gave. If they use this as a
> > > shared key with someone using a correct implementation, they won't be
> > > able to communicate.
>
> > Knowing Java Script as you do, look for a hidden field that is the
> > source for the displayed perm. For those many, entering an improper
> > string directly would be more of a problem, just like you tried.
>
> No, if your form had worked, then the strings I entered would have
> worked perfectly well. And it would be extraordinarily easy to check a
> user's input to make sure it is a valid 65 character alphabet. But
> you're basically admitting that this is an advanced feature that
> requires the user to hack the JavaScript in order to use it. And yet
> the security of the algorithm all but rests on the ability to do this.
> So in essence, they can write the program themselves, or they can use
> your implementation and suffer from a lack of security.
>
> -Brian

Such strange behavior could be allowed with a procedure to treat any
such substitution with a pangram hash to make the results acceptable
before adopting them as a key, but it could be done.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: A link on North Korean home-grwon OS
Next: If we could factor large numbers quickly, how exactly does everything break?