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 22 Apr 2010 05:49
On Apr 21, 8:33 am, bmearns <mearn...(a)gmail.com> wrote:
>
>
> I can't make sense of that sentence, please try again. And you haven't
> addressed the fact that your algorithm is simply a monoalphabetic
> substitution cipher overlaid onto base-64 encoding. Simple frequency
> analysis is the most it would take to break it.
>
If characters of 8 bits were represented in 8 bits, that is
monoalphabetic. Slid down to 6 is not, but 7 could work if for text
you dropped the highest one.
>
>
> > 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.
>
> What does that mean? Are you referring to the fact that you posted the
> script instead of hosting it on a webserver? That's irrelevant, the
> script itself would be available to anyone who wants it either way.

If you see how things are commonly done on the web, I'm right.

> But it's simply ridiculous that your saying the user needs to modify
> the script in order to get security out of it.

That was your objection, not mine. Changes can be made in a page
easily but too many exposed features can be distracting.
>
>
> So by limiting users to weaker crypto, you're protecting them? What
> are you, the NSA?

Most who tamper with source code, even those with a good knowledge of
it, create mistakes that inhibit running.
>
>
> This is not a limitation of the language. JavaScript can easily access
> the value of the field and you can easily check to make sure it's a
> satisfactory alphabet. Here, put this at the top of the scramble
> function, instead of getting Hset$ from "form.set65$.value":
>
....
suggested noted
>
>
> > 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.
>
> It's not strange behavior, you yourself tried to argue that your
> algorithm is secure because the user can change the initial
> permutation, and I've shown that this is pretty much the only place
> that any approximation to security comes from in your algorithm.
> Nothing as convoluted as pangram hashing needs to be applied, just
> check to see if it's got 65 unique characters, exactly as I've done in
> the code above.
>
> -Brian

Secure in taken as an absolute, and this-tire patched coder at
discussion program is just somewhat more secure than it was, not
something to write home about but a good example of some slight
improvements as a result of minimal changes. That's really what you
just did with your suggested additions to source. Of course, such
would need to be explained to use might think a permutation is best
gotten at a beauty parlor. I remind people that such permanents are
really just "temporaries" as truth in labeling is a good thing.

I see that base 32 is almost never used, a useful little thing but
better with other characters, but that would involve Kulu and
Winters...another clue for you.
From: bmearns on 21 Apr 2010 09:33
On Apr 21, 2:16 am, WTShaw <lure...(a)gmail.com> wrote:
> 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:
[snip]
> > > 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.

You're wandering off again. What system are we talking about? A
proverbial system? Because I haven't proposed any systems.


[snip]
> > > 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 can't make sense of that sentence, please try again. And you haven't
addressed the fact that your algorithm is simply a monoalphabetic
substitution cipher overlaid onto base-64 encoding. Simple frequency
analysis is the most it would take to break it.



[snip]
> > 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.

What does that mean? Are you referring to the fact that you posted the
script instead of hosting it on a webserver? That's irrelevant, the
script itself would be available to anyone who wants it either way.
But it's simply ridiculous that your saying the user needs to modify
the script in order to get security out of it.



> > 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.

So by limiting users to weaker crypto, you're protecting them? What
are you, the NSA?



> > 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.

This is not a limitation of the language. JavaScript can easily access
the value of the field and you can easily check to make sure it's a
satisfactory alphabet. Here, put this at the top of the scramble
function, instead of getting Hset$ from "form.set65$.value":

/*************** JavaScript additions *************************/
//var Hset$ = form.set65$.value;
var Hset$ = form.sets.value;
//Remove those tags that WTShaw likes to put around it.
Hset$ = Hset$.replace(/\s*<<65>>\s*/g, "");
Hset$ = Hset$.replace(/^\s+|\s+$/g, "");
//Make sure it doesn't contain any duplicates.
var HsetPassed = "";
for(var i=0; i<Hset$.length; i++)
{
var c = Hset$.charAt(i);
if(HsetPassed.indexOf(c) < 0)
HsetPassed += c;
else {
alert("Error: the alphabet contains duplicate character '" + c
+ "' at index " + i + ".");
return;
}
}
if(HsetPassed.length != 65)
{
alert("Error: The alphabet has to have exactly 65 unique
characters.\n"
+ "Yours has " + HsetPassed.length + " characters.");
return;
}
Hset$ = HsetPassed;
/*************** End JavaScript additions *********************/



> > > > 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.

It's not strange behavior, you yourself tried to argue that your
algorithm is secure because the user can change the initial
permutation, and I've shown that this is pretty much the only place
that any approximation to security comes from in your algorithm.
Nothing as convoluted as pangram hashing needs to be applied, just
check to see if it's got 65 unique characters, exactly as I've done in
the code above.

-Brian
First  |  Prev  | 
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?