Prev: Infinite One-Time Pad, is this product BS?
Next: reverse use of encryption and decryption
From: unruh on 5 Jan 2010 16:08
On 2010-01-05, Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote:
> unruh wrote:
> [snip]
>> Which again argues for opensource OS as well. If something suspicious
>> comes up you can check.
>
> I doubt that an average normal user is in a position (has the knowledge

You did not read. Although that particular user might not be capable,
others are, and with opensource ANYONE can check.Because the manufacurer
knows this they are liable to be more careful to get everything right.

> and time) to check that a file of an opensource OS he downloaded from
> somewhere is absolutely ok, in the sense of free from manipulations.
> Similarly, he can't know whether a piece of hardware he acquires is ok.
> Of course, the probability of bugs should be negligible in general, but
> it might not be exactly zero under some rather unusual contexts (e.g.
> where one or one's organization is the target for manipulations for
> some reasons), I would surmise.

If one has an organization one is hardly "the average normal user" and
the chances taht someone can actually check is much much higher.

And you do not have to accept what is delivered, you can download from
elsewhere instead, and say, run diff to see what the differences are.
>
> M. K. Shen
From: WTShaw on 6 Jan 2010 10:57
On Jan 5, 12:14 pm, unruh <un...(a)wormhole.physics.ubc.ca> wrote:

>
> Secrecy of the cypher IS a form of security defense. But it should not
> be relied on. IF you use your cypher only with one other person, it may
> be a very good defense. If you use it with hundreds, it is a bad
> defense, because someone will leak the details to your opponent-- by
> accident or design.
>
Which takes you back to the key(s), then there are two good rules:
1) Protect the source of the key so that even if you get it by hook or
crook any future keys are kept obscure.
2) Don't betray your key(s) with a from of encryption that utilizes
the whole key. It is better to use an algorithm that never uses key(s)
in a simpleton manner.

Got it? Protect sources. Protect methods; let's call that the Valerie
Protection Protocol
From: Mok-Kong Shen on 6 Jan 2010 12:52
unruh wrote:

> And you do not have to accept what is delivered, you can download from
> elsewhere instead, and say, run diff to see what the differences are.

I certainly believe that opensource is extremely fine. My point is that
one should nonetheless not equate that to "perfectness". For otherwise
there wouldn't have been a need for a rigorously proved kernel
(according to a recent news there was such a task done, involving
considerable effort). Further, if my memory is right, one of the UNIX
creators after long years revealed a backdoor that was detected by
nobody else.

M. K. Shen

From: David Eather on 6 Jan 2010 13:12
WTShaw wrote:
> On Jan 5, 12:14 pm, unruh <un...(a)wormhole.physics.ubc.ca> wrote:
>
>> Secrecy of the cypher IS a form of security defense. But it should not
>> be relied on. IF you use your cypher only with one other person, it may
>> be a very good defense. If you use it with hundreds, it is a bad
>> defense, because someone will leak the details to your opponent-- by
>> accident or design.
>>
> Which takes you back to the key(s), then there are two good rules:
> 1) Protect the source of the key so that even if you get it by hook or
> crook any future keys are kept obscure.
> 2) Don't betray your key(s) with a from of encryption that utilizes
> the whole key. It is better to use an algorithm that never uses key(s)
> in a simpleton manner.
>
> Got it? Protect sources. Protect methods; let's call that the Valerie
> Protection Protocol

Who is Valerie?

What did they do in this field? (I'd just like to know - see, I know of
Kerchhoff and his principle so I know why he is worth listening to and
what he said - I would like to know the same about Valerie)
From: Mok-Kong Shen on 6 Jan 2010 13:26
WTShaw wrote:
> unruh wrote:
>>
>> Secrecy of the cypher IS a form of security defense. But it should not
>> be relied on. IF you use your cypher only with one other person, it may
>> be a very good defense. If you use it with hundreds, it is a bad
>> defense, because someone will leak the details to your opponent-- by
>> accident or design.
>>
> Which takes you back to the key(s), then there are two good rules:
> 1) Protect the source of the key so that even if you get it by hook or
> crook any future keys are kept obscure.
> 2) Don't betray your key(s) with a from of encryption that utilizes
> the whole key. It is better to use an algorithm that never uses key(s)
> in a simpleton manner.
>
> Got it? Protect sources. Protect methods; let's call that the Valerie
> Protection Protocol

I think it would be fine to never "directly" use one's (master) key but
use it to derive keys for encrpting the individual messages through (1)
using it to encrypt time and message no. etc. with e.g. a block cipher
or (2) extending it with such data in case the cipher accepts keys of
variable length. One could also (hierachically) derive from a master
key sub-master keys for use in certain specific time periods (year,
month etc.) as a further measure to protect the master key. For a block
cipher, one could further use the message key in counter mode to
generate keys for actually encrypting the individual blocks to defeat
differential and algebraic analysis, as I recently suggested in another
thread.

M. K. Shen

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Infinite One-Time Pad, is this product BS?
Next: reverse use of encryption and decryption