Re: Newbie Salt and Pass Phrase Question.

Larry Lindstrom wrote:

An administrative account, with access to all of the records,
sounds like a great idea. But if those records are encrypted,
doesn't that limit it's value?

I'm not sure what you mean by "limit its value", there. Do you mean:
"it's a nice idea, but how could it work?" I'll assume the latter for
the moment :-) IOW, you do want admin users, who can access everthing.

There are two /independent/ issues there:
(1) How your code decides whether user 'abc' should have access to
record #123, and
(2) How it actually /provides/ that access (in terms of decyption
etc.).

If you haven't already thought through (1), you need to do that first,
before you worry about (2).

For example:

- Each record might be stamped with the username of the user who
created it, and each user might have a flag which identifes them as an
admin user or not. Then each record should be accessible only to the
creating user, and all users designated as administratve users (however
that might be achieved).

- OR, you might have a table defining a herarchy of usernames; each
user can access the records they created, /and/, the records for all
users designated as subordinates within that hierarchy.

- OR, you might literally have a M:M table relating usernames to
primary keys. Then each user can access the records having primary keys
related to that user. This gives ultimate fine-grained control over who
can access what (but it would normally be overkill).

There are other ways you could approach it, but those are some that
spring to mind. They range from simple & unsophisticated, to more
complex & sophisticated. The question is, what level of functionality
will your users require?

That is something I can't answer. You need to thnk through all the
possible functional scenarios, and decide what needs to happen,
functionally, in each case. For example:
- Tom resigns. Who can now access his records?
- Tom is sick. Fred will work on Tom's records today.
- Tom used to work for Fred, but now Fred works for Tom. Should their
access levels be adjusted?
- Tom accidentally entered records that should have been entered by
Fred.
- The chief adminstrator has forgotten his password,
and so on.

Once you've worked out the system's /functional/ requiremets, /then/
you can work out how to implement those requirements (eg. what crypto
to use).

As I said before, I'm reluctant to advise on the crypto. But if you
clearly state the functional requirements, the folks here will advise
on the crypto. You need to say: "My system must be able to do 'a' and
'b' and 'c' and 'd', how should I achieve that?" 'a', 'b' etc. should
be functional requirements like "there must be adminstratve users who
can access every record", not technical details like "I want to use AES
in CTR mode".

I hope I'm not overcomplicating this for you. But the fact is, it
sounds like you have not fully thought-out the functional requirements
of the system yet. If so, then, any discussuion of crypto details like
ciphers & modes is premature, IMHO.

Hope this helps,

TC (MVP MSAccess)
http://tc2.atspace.com

.

Relevant Pages

  • Re: Update on my Enc+Auth Mode
    ... > Tom St Denis wrote: ... > security system, of which the proper crypto material is ... It's true that at times crypto can be "arbitrary". ... While I think my design is cool ...
    (sci.crypt)
  • Re: Poly1305-AES
    ... > Tom St Denis wrote: ... replaced with an appropriate static memory allocation. ... don't have FPUs handy. ... Also writing a crypto library used all over the ...
    (sci.crypt)
  • Re: Other funny news from CRYPTO03
    ... | Tom St Denis writes: ... |>crypto keep in mind the "best of the best" make mistakes [like using ... | cryptography conference, not a security conference. ... Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org ...
    (sci.crypt)
  • Re: Jim Steuerts Avalanche Cipher
    ... > Tom St Denis wrote: ... >> We all stumble in this field by wanting to design the next best thing. ... Ciphers arise from either ... The problem is unless you're a math phd you have to "grow" into crypto. ...
    (sci.crypt)
Quantcast