I'm very happy with existing GEOM RAID classes, everything from gconcat to graid3. So happy infact, that I'd very gladly see more of them, for example RAID5, or even something like a variation of current graid3, with huge stripe sizes instead of 512byte blocks :) Are there any plans for such things?
On Wed, Dec 01, 2004 at 08:28:40PM +0100, Ivan Voras wrote: > I'm very happy with existing GEOM RAID classes, everything from gconcat > to graid3. So happy infact, that I'd very gladly see more of them, for > example RAID5, or even something like a variation of current graid3, > with huge stripe sizes instead of 512byte blocks :) One thing that would be funny is GEOM XOR, with the possability of setting up two (or more) volumes, such that you write random bytes to one drive, and write the data xored with the random to the other. Introduce RAID3 or 5 and add an extra disk, and you've for N-1 of M redundancy in your heavily encrypted volume. ;) Terje
On Thu, Dec 02, 2004 at 04:59:37PM +0100, Ivan Voras wrote: > >One thing that would be funny is GEOM XOR, with the possability of setting > >up two (or more) volumes, such that you write random bytes to one drive, > >and write the data xored with the random to the other. > > I could easily do that with ggate for fun, if somebody'll use it :) (Of > course, performance will probably suck, it being in userland...) ggate would be one option, but it'd be much nicer to have it as a 'real' geom module. > >Introduce RAID3 or 5 and add an extra disk, and you've for N-1 of M > >redundancy in your heavily encrypted volume. ;) > > Oh yes :) > > A password will still be required, for generating the random sequence... *cringe* The only point of using such a XOR is to end up with an effective OTP (One Time Pad). If you use a password as seed for a simple PRNG, then you're throwing away all the gain, and would be better off with GEOM BDE instead. FreeBSD 5 has a seemingly very good yarrow-based entropy source. Why not use that? The only known perfect encryption algorithm is OTP, assuming your input is perfectly random. If you use a seeded PRNG, then you'd end up reducing the security to that of a regular stream cipher.(Continue reading)
Terje Elde wrote: > One thing that would be funny is GEOM XOR, with the possability of setting up > two (or more) volumes, such that you write random bytes to one drive, and > write the data xored with the random to the other. I could easily do that with ggate for fun, if somebody'll use it :) (Of course, performance will probably suck, it being in userland...) > Introduce RAID3 or 5 and add an extra disk, and you've for N-1 of M redundancy > in your heavily encrypted volume. ;) Oh yes :) A password will still be required, for generating the random sequence...
Terje Elde wrote: > ggate would be one option, but it'd be much nicer to have it as a > 'real' geom module. It would, but I don't know enough to make a kernel module. >> A password will still be required, for generating the random sequence... > > > > *cringe* > > The only point of using such a XOR is to end up with an effective OTP (One > Time Pad). If you use a password as seed for a simple PRNG, then you're > throwing away all the gain, and would be better off with GEOM BDE instead. > > FreeBSD 5 has a seemingly very good yarrow-based entropy source. Why not use > that? > I think I misunderstood something. Do you propose this (for 2 disks): for each block to be written: a) generate a block of random data b) write random data to first disk c) write random data xor user data to second disk(Continue reading)
On Thu, Dec 02, 2004 at 05:16:14PM +0100, Ivan Voras wrote: > I think I misunderstood something. Do you propose this (for 2 disks): > > for each block to be written: > a) generate a block of random data > b) write random data to first disk > c) write random data xor user data to second disk > > So, as long as any person has both disks, the data can be recovered. > Where's the security in that? That you have a filesystem that's not edible unless you have both disks. Typical usage would naturally be for two people to not have the same disks, except for when the filesystem should be accessible. A simple use-case could be using the filesystem to store CA root keys on. The filesystem would thus only be available when both (or all, og N of M) trusted people cooperate in making it available. Pendrives and similar storage could be useful. Terje
Ivan Voras wrote this message on Thu, Dec 02, 2004 at 17:16 +0100: > I think I misunderstood something. Do you propose this (for 2 disks): > > for each block to be written: > a) generate a block of random data > b) write random data to first disk > c) write random data xor user data to second disk > > So, as long as any person has both disks, the data can be recovered. > Where's the security in that? No, the point is to take say, a CDROM which you have preloaded with pure random data, i.e. burncd /dev/random, then you create a proper sized partition, then using gxor you meld the two... Then for any read/write requests, you take the data, read from the OTP, xor the data, and pass it on... Then when you go away, you take the cdrom, w/o it, there is no data... I like the idea, and it would be a perfect project from someone who is learning geom... -- -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
On Thu, Dec 02, 2004 at 10:35:59AM -0800, John-Mark Gurney wrote: +> Ivan Voras wrote this message on Thu, Dec 02, 2004 at 17:16 +0100: +> > I think I misunderstood something. Do you propose this (for 2 disks): +> > +> > for each block to be written: +> > a) generate a block of random data +> > b) write random data to first disk +> > c) write random data xor user data to second disk +> > +> > So, as long as any person has both disks, the data can be recovered. +> > Where's the security in that? +> +> No, the point is to take say, a CDROM which you have preloaded with pure +> random data, i.e. burncd /dev/random, then you create a proper sized +> partition, then using gxor you meld the two... +> +> Then for any read/write requests, you take the data, read from the OTP, +> xor the data, and pass it on... Then when you go away, you take the +> cdrom, w/o it, there is no data... +> +> I like the idea, and it would be a perfect project from someone who is +> learning geom... I was thinking about simlar thing, as we use simlar mechanisms at work to share a secret between a few smart cards. I'm also not sure if CD-ROM with static random data will be safe enough. I want to generate random data before every write, xor data with generated random data and write both. It should also be faster, as I don't need to read random data first. It could be less safe from data integrity point(Continue reading)
On Thu, Dec 02, 2004 at 08:19:54PM +0100, Pawel Jakub Dawidek wrote: > +> I like the idea, and it would be a perfect project from someone who is > +> learning geom... I was thinking of doing this as a excersice for myself, though I don't think I'd be able to find time for it any time soon. > I'm also not sure if CD-ROM with static random data will be safe enough. > I want to generate random data before every write, xor data with generated > random data and write both. It should also be faster, as I don't need to > read random data first. It could be less safe from data integrity point > of view in case of a power failure, when write request reach only one > component. Part of the point of a one time pad is to use it one time. ;) Granted, the chance of someone sniffing the traffic is less relevant for this case than it would be in say, network traffic, but still. > We can also implement both:) > > I think, I can do it quite fast. :) Terje
On Thu, Dec 02, 2004 at 08:19:54PM +0100, Pawel Jakub Dawidek wrote: +> I was thinking about simlar thing, as we use simlar mechanisms at work +> to share a secret between a few smart cards. +> +> I'm also not sure if CD-ROM with static random data will be safe enough. +> I want to generate random data before every write, xor data with generated +> random data and write both. It should also be faster, as I don't need to +> read random data first. It could be less safe from data integrity point +> of view in case of a power failure, when write request reach only one +> component. +> +> We can also implement both:) +> +> I think, I can do it quite fast. I already did it, btw. It is in perforce: pjd_geom_classes. -- -- Pawel Jakub Dawidek http://www.wheel.pl pjd <at> FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
RSS Feed12 | |
|---|---|
16 | |
11 | |
10 | |
36 | |
20 | |
9 | |
25 | |
36 | |
25 | |
33 | |
55 | |
41 | |
36 | |
30 | |
11 | |
27 | |
13 | |
22 | |
86 | |
41 | |
16 | |
21 | |
63 | |
64 | |
41 | |
19 | |
21 | |
72 | |
42 | |
65 | |
41 | |
52 | |
66 | |
43 | |
28 | |
37 | |
97 | |
85 | |
24 | |
43 | |
25 | |
30 | |
24 | |
39 | |
42 | |
49 | |
55 | |
58 | |
53 | |
66 | |
28 | |
65 | |
108 | |
59 | |
52 | |
35 | |
20 | |
29 | |
46 | |
38 | |
32 | |
41 | |
37 | |
37 | |
23 | |
43 | |
67 | |
65 | |
44 | |
35 | |
102 | |
66 | |
117 | |
113 | |
70 | |
175 | |
86 | |
46 | |
68 | |
83 | |
125 | |
77 | |
63 | |
42 | |
69 | |
64 | |
61 | |
69 | |
78 | |
35 | |
50 | |
56 | |
38 | |
41 | |
21 | |
21 | |
40 | |
39 | |
48 | |
39 | |
38 | |
41 | |
36 | |
92 | |
17 | |
19 | |
18 | |
29 |
