Cryptography-Digest Digest #339, Volume #13 Fri, 15 Dec 00 19:13:00 EST
Contents:
Re: Custom Encryption Algorithm ("Phil Massimi")
Re: Custom Encryption Algorithm ("Phil Massimi")
Re: Protocol for computer go (Marc)
Re: security by obscurity ... (Marc)
Re: Protocol for computer go (Marc)
Re: binary vs. text w/ regard to digital signatures (Marc)
Re: Encryptian of data over radio transmission (Marc)
Re: Protocol for computer go (Francois Grieu)
Re: NT4 Password ("bubba")
Re: Q: Result of an old thread? (Mok-Kong Shen)
Re: Sr. Cryptographer/mathematician (David A Molnar)
Re: Protocol for computer go (David Schwartz)
Re: Custom Encryption Algorithm (David Schwartz)
----------------------------------------------------------------------------
From: "Phil Massimi" <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sun, 10 Dec 2000 01:34:47 GMT
> > > Even though you have not given me an algorithm to work with, i can
> > > point out some flaws in this cipher just by looking at the cipher-
> > text.
> > > e.g. You have a row of 9 ones in succession. If this were a good
> > > cipher, then you would have an even distribution of digits. However,
> > > the probability of a string of nine '1's occuring in a row is 1/10^9
> > or
> > > one in a billion.
> > >
> > > Based on this, I conclude your algorithm isn't very secure.
> >
> > Your observation is correct however your conclusion is not. A valid
> > RNG may output a zillion zero bits and still be random. You observed
> a
> > bias in his cipher, perhaps due to the fact it's probably some sort of
> > simple monoalphabetic substitution mixed with a Vinegere cipher. Who
> > knows. Just because there are alot of 1's doesn't make it weak.
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
> Yes, i agree with this. It is quite feasible that the text given above
> could have been a random source. But since he said the sample was
> produced by an algorithm that encrypted non-random plain-text, the lack
> of randomness would indicate a poor cipher.
>
> This said, secure ciphers can be designed with compressable cipher-
> text. The compressability of a document is dependent on the amount of
> entropy the document contains and thus its randomness. Generally, the
> more random the less compressable. So although the randomness of the
> sample can be a good indicator of security, it is nothing hard and fast
> and can be quite wrong in somecases.
>
> Simon.
Tom, Simon... thank you very much... this is the type of info I was looking
for (even though you chewed me out first Tom :P). That's exactly what I
wanted to know... if by looking at the cipher-text itself, if some liability
could be seen. Thanks again. :)
Phil
------------------------------
From: "Phil Massimi" <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sun, 10 Dec 2000 01:29:51 GMT
>> Oh -- so if there's no key, the encryption becomes uncrackable? <g>
> No, it becomes useless. You have to trust everyone who has ever used
> the algorithm in order to trust the algorithm.
Well, technically speaking, the algorithm that converts the ciphertext back
to plain text IS the key, right? Like I said, I'm an amateur at this... but
I assure you, I can reverse the algorithm and convert that mess back into
"plain-text", which means there IS a key. When I originally said there were
NO keys, I was referring to the type of thing you see in PGP.
> You'll notice in this case that the poster has so little confidence in
> his algorithm that he has provided no information whatsoever. For
> example, no plaintext/ciphertext pairs are offered. No information about
> its architecture is offered.
>
> He might as well have said, "I have thought of a great algorithm and
> challenge anyone to break it. If you break it email me."
>
> DS
Heh heh heh... well, I appreciate the input. However, my question would be
this: why in the world would I give you plaintext/ciphertext pairs, or
information about its architecture, or any other clues whatsoever? The
whole POINT is to encode text in such a way that it can't be intercepted by
people with NO KNOWLEDGE of the algorithm, and have the "cipher-text" easily
analyzed to find patterns, and consequently decoded by "unauthorized
personnel". If I give you clues, and you figure out how to decode my
"cipher-text", that tells me nothing whatsoever... maybe you would have
figured it out without my clues, and maybe not. But if I give you no clues,
and you can decode it anyway, then it's pretty obviously insecure.
Well, in any case, I just thought there might be some people reading this NG
that might enjoy the challenge. Excuse my ignorance, but I will point out,
I TOLD you I was no expert. :P If ignorance offends you, then you must be
in a bad mood ALL THE TIME... because there are a whole lot more ignorant
people out there than just me. :P
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Protocol for computer go
Date: 15 Dec 2000 23:14:28 GMT
> *how many* operations the program takes, which is what the
> cycle counter should be counting.
If the contest participants were limited to use an interpreted
(tokenized) programming language, the interpreter would have
full control over the cycle consumption of the participants.
The overtime limit could be expressed in cycles instead of
seconds. The actual execution speed would be of no significance.
The interpreter could be a watch guard, too, and keep the
participating programs from communicating via covert side
channels with their developpers.
A version A of the interpreter could be given out to the developers
before, while a "security enhanced" version B is used throughout
the tournament. The developers would have a hard time guessing
and abusing bugs, because they don't get to see version B until
after the contest and can not modify their programs anymore.
Test suites are required to ensure that both versions handle
the interpreted programs cycle-exact.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: security by obscurity ...
Date: 15 Dec 2000 23:14:38 GMT
>Often security via obscurity doesn't even involve secret
>keys/algorithms. Just "oh I xor'ed a 0x55' to secretly encrypt
>everything...
I recently saw a commercial device to protect its data by
XOR with the text string "GUINNESS!" and hiding the result
in a block of random data (a rom table was used to pull out
the right bytes for "decryption").
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Protocol for computer go
Date: 15 Dec 2000 23:14:44 GMT
>Yes, you're right. Probably what you want to count is number
>of instructions computed, not how many clock cycles they've taken.
A busy loop
while (!non_deterministic_event()) ;
can convert any of those non-deterministic influences into
a non-deterministic count of instructions computed.
Certainly most if not all hardware drivers (gfx, disk, etc)
contain such code snippets.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: binary vs. text w/ regard to digital signatures
Date: 15 Dec 2000 23:14:51 GMT
>The fact that tilde-n has one and only one encoding does not help use
>avoid the fact that two different sequences have precisely the same
>visual effect.
In many fonts the 0 and O (digit zero and uppercase o) have the same
visual effect, too. Like for example the one I am typing with.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Encryptian of data over radio transmission
Date: 15 Dec 2000 23:14:56 GMT
>How can i encrypt voice data over FM. Schematics would be appreciated.
>Basically looking for a addon for a FM transciever i have. Also
>schematics for the decryptor
This is the box of Pandorra. The answer to your question can
scale anywhere between "simple add-on IC" to "all digital voice,
celp/gsm vocoder, error control/correction protocol, key exchange
and block cipher".
For an easy solution look for the FX118 chip (Radio Shack), which
can be used to invert the voice. Many analog cordless phones use a
comparable chip, and the better radio scanners have "decoders"
built-in for that reason.
For the hard (but secure!) way look into solutions like Nautilus
or PGPphone for your PC, and translate their functionality to
a selfmade embedded device to attach to your FM radio. Involves
knowledge of HAM, DSP, crypto, and electronics.
I once wanted to build the latter for POTS telephony, but never
got around to do it.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Sat, 16 Dec 2000 00:17:41 +0100
David Schwartz <[EMAIL PROTECTED]> wrote:
> Francois Grieu wrote:
>
> > I think I have found a similar solution: have the play program B, or a
> > referee, tell how much time (real, not estimated) program B has used,
> > after
> > each move. Put that in the transcript. Give this info to play and replay
> > program A (do not give time used by play program A to replay program A).
> > Play and replay program A shall identically translate time used by B into
> > how much work the play program A could accomplish while B though its
> > move;
> > play program A shall first finish this work, if not already done (program
> > A
> > must either avoid doing work in advance of the estimation, or be able to
> > back up), so that replay program A can be kept in sync; replay program A
> > should do just this amount of work. Of course if the programmer does not
> > like this mess, it is possible to just do some small fixed amount of work
> > while B prepares its move.
>
> I don't see how this could work. The only way to know how much actual
> work the program got done while its opponent was thinking is to ask it.
> For all the reasons previously discussed, there is no way to turn wall
> clock time into exactly how much work a computer can get done. The basic
> rules of the game allow each player to do as much thinking as the player
> is physically capable of. And the only way to know how much thinking a
> computer did in a fixed amount of wall time is to ask it, which creates
> obvious side channels.
Suppose the play program A has execution time dominated by calls to some
evaluation function, taking t=0.01s at each call, on the hardware used by
program A, and this constant t is known by both program A and replay
program A (the programmer knows its hardware).
After program A has announced its move, program A starts evaluating. In the
meantime program B produces its move after T=10 second. Program A receives
this information T together with the move of B, before it has made 1000
evaluations, say only m = 950 evaluations. Program A decides to make
exactly T/t-m = 50 additional evaluations before even considering the
answer given by B, for a total of exactly T/t = 1000 evaluations.
Now replay program A, running on a different hardware (say much slower)
replays the game. Right after it has announced its move, replay program A
obtains T=10 (recorded in the transcript used by the referee). Since this
info was in fact obtained from the behaviour of program B, it is not a
directly usable side channel for replay program A. Replay program A makes
T/t=1000 evaluations, just like his fellow program A did, although it might
take much much more than 10 second of real time to do so on the replay
hardware. Program A and replay program A are in sync, and play program A
has made good use of the CPU available. The more accurately the programmer
is able to predict the work performed by program A from the time taken by
the other program, the less overhead there is.
It is complex, but I do think it works.
If the programmer for A does not like the idea of using some of its own
time to finish the computation necessary to keep the replay program A in
sync, it can instead use a higher value of t than the observed 0.01s, say
t=0.012s, used by both program in the same formula as above; program A will
have done more evaluations than replay program A will. Program A must back
up and loose some work (this is uneasy, but doable) and has lost some of
the time used by B, but none of its clock time.
Unfortunately, net lag comes into the picture and probably makes it
necessary that the play program can both back up and do some extra work.
Francois Grieu
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: NT4 Password
Date: Fri, 15 Dec 2000 23:25:12 GMT
I am not a big unicode user, but wouldn't it be something like 0x0061?
"Mike The Man" <[EMAIL PROTECTED]> wrote in message
news:OIs_5.4206$[EMAIL PROTECTED]...
> Hi!
>
> Could anyone explain to me how the clear-text password is encrypted in NT.
> I understand it's Unicoded and then hashed with MD4, but it doesn't work
> with my MD4-app.
> If the password is 'a', shouldn't the Unicode be '6000' in hex?
> If I feed 6000 into the MD4 it doesn't come out the same way as in
> L0phtcrack?
> So I guess there's something wrong with the Unicode (I've run all the
tests
> in the MD4 rfc in my app).
>
> Thanks!
> Mike
>
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Sat, 16 Dec 2000 00:25:52 +0100
Bryan Olson wrote:
>
[snip]
>
> There's the problem that S is singular, so AS will
> also be singular. While you can't get an inverse
> and find a unique solution for B, you can set up the
> linear equations to solve for B, and use _any_ of the
> non-singular solutions.
Could you elaborate a bit, perhaps with a mini-example?
Thanks.
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Sr. Cryptographer/mathematician
Date: 15 Dec 2000 23:17:17 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> "Matt Timmermans" <[EMAIL PROTECTED]> wrote:
>>
>> Ottawa is not _that_ big a city, Tom -- you already work there!
> And your point being?
I think he's trying delicately to make the point that you are working for
Cloakware. You are working for cloakware, aren't you?
You said as much in
http://www.deja.com/getdoc.xp?AN=702141012&fmt=text
(not sure if that link will work - but type "tom st. denis cloakware"
into deja.com and it'll pop right up)
The ad is almost certainly from cloakware - unless there's some other
code shrouding company in Ottawa.
Then if I had to guess, I'd say the next point would be something along
the lines that it seems strange to both be working for a company and then
savaging its aims the way you did in the thread. Just a guess.
It's fine and perfectly normal to disagree with an employer. (I'm actually
very sympathetic to such a position). It's not so fine to rudely make fun
of your employer in public, *especially* when not all the onlookers know
that you work for cloakware. Go ahead and make fun of them, but add a
disclaimer like "and by the way, I work for a company doing the same
thing." Doing anything else seems dishonest.
And if the ad _isn't_ from cloakware, then you're attacking a company
without revealing that you work for a competitor, and that seems pretty
bad, too.
Just my opinion, of course.
I'm e-mailing you about this because I can't figure out if you realize
what he meant or not. For some reason this bothers me.
Feel free to tell me to fuck off if you feel like.
-David
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 15:28:30 -0800
Francois Grieu wrote:
> > I don't see how this could work. The only way to know how much actual
> > work the program got done while its opponent was thinking is to ask it.
> > For all the reasons previously discussed, there is no way to turn wall
> > clock time into exactly how much work a computer can get done. The basic
> > rules of the game allow each player to do as much thinking as the player
> > is physically capable of. And the only way to know how much thinking a
> > computer did in a fixed amount of wall time is to ask it, which creates
> > obvious side channels.
> Suppose the play program A has execution time dominated by calls to some
> evaluation function, taking t=0.01s at each call, on the hardware used by
> program A, and this constant t is known by both program A and replay
> program A (the programmer knows its hardware).
It's rather silly to assume that there is but a single evaluation
function that will take the same amount of time every time it's called.
Far more realistic is that there's a complex evaluation cluster of
functions that, for example, sometimes needs to invoke a tactitian and
sometimes doesn't. (Perhaps you're not familiar with Go or how typical
Go programs are structured?)
> After program A has announced its move, program A starts evaluating. In the
> meantime program B produces its move after T=10 second. Program A receives
> this information T together with the move of B, before it has made 1000
> evaluations, say only m = 950 evaluations. Program A decides to make
> exactly T/t-m = 50 additional evaluations before even considering the
> answer given by B, for a total of exactly T/t = 1000 evaluations.
But if it has gone past that number of evaluations, it has to lose
information. And if it hasn't gotten anwyhere near that number of
evaluations, it has to lose time. So if the program does a poor job of
estimating how much evaluation it can do, it will be penalized in its
game play. This rewards simple algorithms and punishes complex
algorithms.
> Now replay program A, running on a different hardware (say much slower)
> replays the game. Right after it has announced its move, replay program A
> obtains T=10 (recorded in the transcript used by the referee). Since this
> info was in fact obtained from the behaviour of program B, it is not a
> directly usable side channel for replay program A. Replay program A makes
> T/t=1000 evaluations, just like his fellow program A did, although it might
> take much much more than 10 second of real time to do so on the replay
> hardware. Program A and replay program A are in sync, and play program A
> has made good use of the CPU available. The more accurately the programmer
> is able to predict the work performed by program A from the time taken by
> the other program, the less overhead there is.
>
> It is complex, but I do think it works.
It works in the sense that it allows the replay. It doesn't work in the
sense that it robs the computer, during actual game play, of the ability
to decide how much processing it can/will do while its opponent is
thinking.
> If the programmer for A does not like the idea of using some of its own
> time to finish the computation necessary to keep the replay program A in
> sync, it can instead use a higher value of t than the observed 0.01s, say
> t=0.012s, used by both program in the same formula as above; program A will
> have done more evaluations than replay program A will. Program A must back
> up and loose some work (this is uneasy, but doable) and has lost some of
> the time used by B, but none of its clock time.
In other words, it either has to throw away work it has done or lose
clock time. So the question becomes, how well can an algorithm predict
ahead of time how much work it can get done in a particular board
situation. However, in reality, this varies with the complexity of the
board situation. If a large number of groups are in life or death
struggle, evaluation takes much longer as a tactician has to be invoked.
If not, only the much faster strategist needs to be consulted. So this
rewards simple algorithms and punished sophisticated ones.
> Unfortunately, net lag comes into the picture and probably makes it
> necessary that the play program can both back up and do some extra work.
Isn't it bad enough already that nondeterminstic algorithms are being
penalized? How good a Go came do you think most humans could play if
*they* were required to play deterministically?
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Fri, 15 Dec 2000 15:31:35 -0800
Phil Massimi wrote:
> Heh heh heh... well, I appreciate the input. However, my question would be
> this: why in the world would I give you plaintext/ciphertext pairs, or
> information about its architecture, or any other clues whatsoever?
Because someone realistically trying to break your algorithm would have
this information.
DS
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
