> David Wagner taverner.cs.berkeley.edu> wrote:

>>Kristian Gjøsteen wrote:

>>>Markus.Dichtl.nospam@googlemail.com wrote:

>>>>And since I argue that IACR, if it has published a wrong paper, a moral
>>>>obligation to publish as well a paper, which corrects the wrong one, I
>>>>had to indicate which was the wrong one.

>>>
>>>Nah. The program committee has an obligation to produce a worthwhile
>>>scientific program for the conference. Accepting papers that point out
>>>that previous program committees made mistakes may run counter to that
>>>obligation (eg. if the mistakes aren't sufficiently interesting).

>>
>>I'm with Markus here -- especially for FSE. I do think the committee
>>has, or should have, a rough obligation to publish correct, novel, and
>>well-written breaks of papers that were accepted at the same conference
>>the prior year. How else will we, as a field, correct and learn from
>>our mistakes?

>
> Suppose I write a correct, well-written one-page note saying that Thm 2 ...

> Peter van Liesdonk wrote:
>

>> There is no such concept as a password. If there would be a password as
>> you propose, then it would be all the info required to encrypt/decrypt,
>> and thus be the key. A brute force attack would just try any likely
>> password.

>
> Let me explain what i ment by password and why i propose to use it:
> What ever user enters either by keyboard or stored in a particular file
> is a password. This can be a short sting. For examnple let is be 64
> bits long. Now the Encryption/Decryption key is 2048 or more bits long
> and deterministic translation of the password to a key is a time
> consuming process. It is time consuming not because of a poor algorythm
> but because the mathematical model connecting the two is difficult,
> like large matrix inversion or simmilar. The purpose of doing this is
> to give attacker 2 brute force routs to take:
> 1) Bruteforsing the password
> 2) Bruteforcing the key
> ...

> blackwingbear@gmail.com wrote:

>> This is SPAM

>
> Yes, but for a good social cause
>

>Aidan Kehoe wrote:

>> Ar an chad l is fiche de m na Samhain, scrobh frisbieinstein@yahoo.com:

>>> I thought the reason Navajo was so secure was that it used sounds
>>> completely unfamiliar to the German ear. So it was not possible for
>>> them to transliterate it.

>> Also relevant, and probably more so, was that its usage in the European
>> theatre of operations was minimal; its formal use was mainly in the Pacific.

> Yes, they chose a dialect that had never been studied by Japanese
>anthropologists.

> Tom St Denis wrote:

>> Stratocaster wrote:
>>

>>>Absolutely.Another issue that is relevant is spending millions for your
>>>security and allowing your information that is sensitive to be accessed
>>>from any point other than a direct pipe.Happens all the time.Stupid.I
>>>recommend to clients that if you have sensitive information, boil it
>>>down to absolutes, and keep it on paper in a safe, and make people
>>>initial it when signing it out-like the CIA does.Too much work?Then you
>>>arent serious about security, or your spending is out of line with the
>>>secrets you want to keep.

>>
>>
>> That sounds all l33t and all, except how do I order stuff off amazon
>> with a credit card in a safe?

>
> Credit cards are far from having/being sensitive information --- at
> least for the definition of sensitive that the previous message
> suggests. ...

>Don't overlook the scenario where a third party is trying to protect
>secrets on your machine...

>Tom St Denis wrote:

>> The attack is not that you run your security on other machines, rather
>> that people can run code on YOUR machine.

>
>There are other scenarios. Sometimes a third party is trying to
>protect secrets on your machine (think DRM).

> In practice, with today's commodity operating systems, if an attacker can
> run code of his choice on your machine, I tend to think you're probably
> screwed anyway.