|
|
 Up |
|
|
  |
Author: David WagnerDavid Wagner
Date: Sep 30, 2006 19:30
D. J. Bernstein wrote:
>The fastest secure protocols I've seen keep two keys (the master key and
>the derived key) instead of one key. This means that those protocols can
>fit fewer simultaneous sessions into cache---i.e., that fewer sessions
>can survive a denial-of-service attack.
As far as I know, for most applications, the master key doesn't need to
be in cache, since it is only rarely used (it is only used when you need
to derive a new derived key, which is a rare event).
>Of course, this speed problem is like the invertibility speed problem in
>that it's shared by every 128-bit-block cipher. Some of the AES problems
>can be fixed within the restricted structure of a 128-bit-block cipher,
>but others can't.
Yup.
|
| |
|
| |
3 Comments |
|
|
Author:
Date: Sep 30, 2006 16:03
I have a feeling this is a common problem, so I want to hear from people
more knowledgable about how to go about it:
This is the requirement: some pieces of data in publically accessible
database needs to be hidden from (many) users that can normally read the
entire database, and be accessible by (several) privileged users.
My intent is to do it like this:
- create a random key (e.g. 128 random bits) & encrypt the data with
this key
- encrypt that key with passwords of users that have access to the data
(i.e. for X users, X copies of the above key would be encrypted
separately with users' keys and stored) Strengths of user passwords is a
separate and unrelated issue for this :)
I guess encrypting one piece of data (the master key) several times
independantly (but with a prepended salt) will make it somewhat easier
for brute-forcing, and make it much more vulnerable if one of users'
passwords is stolen.
Any suggestions or improvements on the plan?
|
| |
|
| |
11 Comments |
|
|
Author: David WagnerDavid Wagner
Date: Sep 30, 2006 14:45
Cristiano wrote:
>my proposed cipher [is] an usual SSG which uses a 19937-bit LFSR
Yup, I recognize that, and nope, it doesn't change any of my comments.
|
| |
|
no comments
|
|
|
Author: CristianoCristiano
Date: Sep 30, 2006 11:18
David Wagner wrote:
> D. J. Bernstein wrote:
>> 1. The fastest AES software is too slow for some applications. [...]
>>
>> 2. The fastest timing-attack-protected AES software is even slower,
>> [...]
>
> Self-shrinking MT19937 isn't going to cure any of those criticisms.
>
> (I see that you changed the Subject: line, but the topic of this
> thread, and the context for my assertions, was a proposal for a new
> stream cipher, a self-shrinking version of Mersenne Twister. I
> believe my comments were accurate in the context they were made.)
If you still don't understand that there is no "self-shrinking version of
Mersenne Twister" your comments cannot be accurate.
Please, throw away the Mersenne Twister from your mind and consider my
proposed cipher as an usual SSG which uses a 19937-bit LFSR (which is what
my cipher is).
Cristiano
|
| |
|
no comments
|
|
|
Author: David WagnerDavid Wagner
Date: Sep 30, 2006 10:26
D. J. Bernstein wrote:
>1. The fastest AES software is too slow for some applications. [...]
>
>2. The fastest timing-attack-protected AES software is even slower, [...]
Self-shrinking MT19937 isn't going to cure any of those criticisms.
(I see that you changed the Subject: line, but the topic of this
thread, and the context for my assertions, was a proposal for a new
stream cipher, a self-shrinking version of Mersenne Twister. I believe
my comments were accurate in the context they were made.)
>3. The fastest AES software that can safely encrypt massive data sets is
>even slower, [...]
I question that assertion. It's not significantly slower. The
performance impact of re-keying after every 2^40 bytes is negligible.
|
| |
|
1 Comment |
|
|
Author: David WagnerDavid Wagner
Date: Sep 30, 2006 10:22
D. J. Bernstein wrote:
>David Wagner taverner.cs.berkeley.edu> wrote:>> AES is almost never the weakest link of any real-world system.
>
>Tromer et al. extracted the Linux disk encryptor's secret key using a
>cache-timing attack on AES. This attack would have been impossible if
>the AES software had been replaced by (e.g.) Serpent software.
Mersenne Twister-SS is not going to improve security against that
kind of threat.
|
| |
|
no comments
|
|
|
Author: Harry ThompsonHarry Thompson
Date: Sep 29, 2006 17:39
"rossum" coldmail.com> wrote in message
news:gb9rh2da3iuijclpkv2oj2oblkheht7i71@4ax.com...> On Fri, 29 Sep 2006 21:47:47 +0100, "Sean"
> gmail.com> wrote:
>>>Hi all,
>>
>>I am currently in my last year BSc. Computer Science & Software
>>Enginnering.
>>I have a subject 'Cryptology/Cryptanalysis' in which we are given some
>>ciphertext throughout the year to decipher.
> Be aware that we don't do homework for you.
>
>>
>>It is only the end of the second week and we have not covered any
>>encyption
>>schemes in depth(yet) so from my understanding the ciphertexts below are
>>encypted using a "Classical" approach.
>>
>> ...
|
| Show full article (1.73Kb) |
|
no comments
|
|
|
Author: CristianoCristiano
Date: Sep 29, 2006 16:13
David Wagner wrote:
> Cristiano wrote:
>> Nothing wrong with AES, Serpent, Salsa, and so on, but you snipped
>> the most important thing (in my view): they all have a very complex
>> construct when compared to my cipher. As I said, I think it is
>> reasonable to say that a complex construct could hide some
>> unexpected vulnerabilities, while it is unlikely to find any new
>> vulnerabilities in an old, well known and simple scheme like the SS
>> generator (it's just an LFSR).
>
> That reasoning sounds dubious to me. I think AES has been a lot
> better studied than your Mersenne Twister - SS cipher.
There is no doubt; I guess nobody in the world has studied MT-SS cipher, but
many mathematicians and cryptographer studied the SS generator. My cipher is
not different from any other SSG, it is an SSG with a 19937-bit LFSR,
nothing else.
> I'd have more confidence in AES.
|
| Show full article (2.45Kb) |
|
no comments
|
|
|
Author: Ben LivengoodBen Livengood
Date: Sep 29, 2006 16:08
Mike Amling wrote:
>
> The only data that you keep is the "result" concatenation of sorted
> unique "longhash"es (bad name; They're bit strings formed by
> concatenation, and not hashes.), right? I'm discarding final values
> assigned to the nodes. There is no marker between the list from one
> iteration and the appended list from the next iteration, but none should
> be necessary. And, mea culpa, I kept only a 32-bit hash of the results,
> not the results themselves (but I can hardly believe there've been 991
> collisions).
>
|
| Show full article (4.13Kb) |
|
1 Comment |
|
|
|
|
|
Author:
Date: Sep 29, 2006 15:23
Thomas Pornin nerim.net> wrote:>According to Kristian Gj
|
| |
|
no comments
|
|
|
|
|
|
|
