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 15 Apr 2010 02:27
On Apr 14, 12:11 pm, David Eather <eat...(a)tpg.com.au> wrote:
> On 14/04/2010 4:55 PM, WTShaw wrote:
>
>
>
> > On Apr 11, 1:14 am, David Eather<eat...(a)tpg.com.au>  wrote:
> >> You wrote a whole program and even years later thought it something that
> >> everyone should know about.
>
> >> You wrote a whole program to calculate this:
>
> >> equivalent number of bits = log(N!) / log(2)
>
> >> where N is the number of objects to be permuted.
>
> >> Sorry, anyone who did any formal maths already knows that, as does
> >> anyone who studied cryptography for any length of time and they don't
> >> need a table of repeated calculations. They can already directly
> >> calculate it for any value they desire. Even better, by replacing log(2)
> >> with log(X) they can calculate it to any value to base X as well.
>
> >> You don't even know what you don't know. You would be best served by
> >> listening and asking genuine questions.
>
> > While your figures are correct in general, the route I took was to
> > actually simulate the real process.
>
> Which just shows you wasted a lot of time.
>
> Your figures will not always match
>
> > the real experimental values.
>
> Oh? Please give an example.

The program was not difficult, not any more effort than one that did
each entry separately...but it generally verified the formula as a
good generalization.
From: Mok-Kong Shen on 16 Apr 2010 03:08
WTShaw wrote:
[snip]
> ....... Many years ago
> it was my posting of the relationships between bases as the general
> formula based of logs that attracted attention as common knowledge
> never got that far, so my data is attacked with my own results,
> curious.

I am not clear of what you mean exactly in this point. (I know from
math formulae those of change of bases of logs,) I remember though
some posts of yours about using change of bases in crypto. BTW, a
point of my personal interest: When did you first post on the issue of
change of bases? I once noted down a reference of 1988.

M. K. Shen


From: bmearns on 16 Apr 2010 10:29
On Apr 15, 2:24 am, WTShaw <lure...(a)gmail.com> wrote:
> On Apr 14, 8:23 am, bmearns <mearn...(a)gmail.com> wrote:
>
> > On Apr 14, 3:16 am, WTShaw <lure...(a)gmail.com> wrote:
>
> > > On Apr 12, 11:38 am, bmearns <mearn...(a)gmail.com> wrote:
>
> > > As there are almost infinite ways to do this, you reject any method
> > > that you cannot control.
>
> > No, I reject any method that is demonstrated to weaken the key.
>
> So you'd rather walk than ride?

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.



> The so called secret beyond anything
> else would be an initial state permutation.  In tests, I tend to use
> the normal alphabet for base 26 but there is no reason not to start
> with an permutation.  Therefore a different domain would be created
> with same entries using different initial states.
>
> So, if you took that base64 coder scheme and changed the pasted in set
> string, you would do the same thing whetehr or not my way of varying
> the permutation on the fly was used at all.  We have no idea what a
> person might do to get such a permutation as desired. The character
> set could also be different as long as it had 64 or 65 characters with
> identical algorithm treatment; maybe then it would be derivative
> algorithm.

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.

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.

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.

>
>
>
> > > My answer is that it is right to encourage
> > > private generation of complex keys because that is often where real
> > > strength lies and always does in ideal systems, or should. Making keys
> > > has nothing to do with the actual encryption algorithm except meeting
> > > operational runtime critera.
>
> > So you're suggesting security by obscurity. That's fair enough; some
> > people support that. I personally do not, but that's just a difference
> > of opinion. The problem is that you're putting up this "web
> > application" to generate permutations with an algorithm you've
> > designed, and so you've lost the obscurity. You're sharing your
> > algorithm with others and apparently trying to convince others to use
> > it, so it needs to be an intrinsically strong algorithm, not just
> > strong because no-one knows what you're doing.
>
> Now, go back to the classic definition where keys are supposed to hold
> the nature of strength given a realistic encryption scheme.  It's not
> security by obscurity if you must reveal the key you use or how you
> got it, remembered it, or hide it, quite the contrary; you can't have
> it both ways.

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?


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

At what point do you think I defined a set of allowed keys?


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

From: WTShaw on 17 Apr 2010 02:55
On Apr 16, 2:08 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> WTShaw wrote:
>
> [snip]
>
> > .......  Many years ago
> > it was my posting of the relationships between bases as the general
> > formula based of logs that attracted attention as common knowledge
> > never got that far, so my data is attacked with my own results,
> > curious.
>
> I am not clear of what you mean exactly in this point. (I know from
> math formulae those of change of bases of logs,) I remember though
> some posts of yours about using change of bases in crypto. BTW, a
> point of my personal interest: When did you first post on the issue of
> change of bases? I once noted down a reference of 1988.
>
> M. K. Shen

A long time ago but maybe a cohort might have posted that early. I
lurked for a long time, but I very busy going at things largely on my
own about then. The refined topic is called base translation or ways
to go between bases, even via intermediate ones. There are many good
examples, but I'll be talking about single translations for now. As
my interests are mainly are in messaging, the programs usually have a
built-in front end to deal with raw formats.

It would be easy to see that base 27 and base 81 are 100% in
conversions but lesser rates are OK, high 90's are better.
The idea with BT is that a value equal a power of the one base is
slightly greater than a power of an originating base. Recently, I've
been converting some of the old programs to Java Script which is quite
adequate. My postings were so long ago the Google has forgotten most
of them, but not all.
From: WTShaw on 17 Apr 2010 03:07
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.
>
>
> 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?
>
> 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.
>
> 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.
>
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?