uosɐſ
Reputation
Next privilege 150 Rep.
Create new tags
 Mar 7 comment Homomorphic encryption for vector addition I felt silly explaining this as my goal, but the motivation is for a 3D space which is most efficiently explored with ⊕. That in some kind of game you'd start in a coordinate with no concept of where you are in the plaintext space, but you can move relatively through it. The hyperlinearity was to enforce energy costs for traveling, so you can't just zoom through it. Also, perhaps as in our own physical universe, there would be no (known) center/origin. Silly thoughts, but yours is a great answer, thanks! Feb 6 comment Homomorphic encryption for vector addition Oh, ok. I am ok with anything with a large and identical p,q,r. Three signed 64-bit values is plenty for this. Feb 5 comment Homomorphic encryption for vector addition @mikeazo - do you want to add an answer about the SIMD FHE you mentioned on the other question comment? Feb 5 comment Homomorphic encryption for vector addition D.W. - Thanks for the added detail. I tried to get some help understanding your response on chat, but didn't get far. What is the significance of p, q, and r? My first guess is that it is related to the bit-size of x, y, and z since Z/pZ is an integer field mod p, right? - so 2^32 if they're 32-bit (although signed is preferred). But I think that's a bad guess since you seem to anticipate that p, q, and r would be different and perhaps prime. Jan 31 comment Addition-only PHE in F# ok, ready: Homomorphic encryption for vector addition I did not mention SIMD because I didn't want to steal your thunder. Jan 31 comment Addition-only PHE in F# But if I wanted to extend this to multiple dimensions, I'd need Gentry? $(\varepsilon(x), \varepsilon(y), \varepsilon(z))$ is not as ideal as $\varepsilon((x, y, z))$ because I don't want the components to be reusable independently like that. Is there an encoding of $(x, y, z)$ that makes it compatible with the simple $\oplus$? Jan 31 comment Addition-only PHE in F# Thanks! The padding thing was due to my impression that HE is an undesirable property normal crypto uses and thus padding is added which interferes with HE, i.e. multiplication in RSA. But whatever, this is good info, thanks. Aug 22 comment Security considerations for partially shared password databases Ok, I guess that could work, setting it to 1. But that particular algorithm is intended for a different purpose of dividing the secret - not just sharing it. I think the same benefit can be achieved with more common algorithms, is all. Aug 22 comment Security considerations for partially shared password databases Also, Shamir's Secret Sharing is when I'd want /some or all/ of the members to be necessary to decrypt the key. This is not good for my intended use. Aug 22 comment Security considerations for partially shared password databases Yes, KeyPass with the ability to share one of your secrets with someone else's database. What multiple layers of shared secrets do you mean? Aug 22 comment Security considerations for partially shared password databases It's not concurrent write access - that's the point of one file per user. I write to my database my own secrets. I have a list of trusted targets (each family member's public key read from their database). Each of my secrets' keys are encrypted using my own public key, but also (separately) by the public keys of each share target that I have chosen. They can read from this file and decrypt the shared secrets' keys with their private key. Aug 22 comment Security considerations for partially shared password databases Great links. Thanks. Yeah, I'd like to avoid domain-specific services. I see value in a scheme that doesn't require a server or many moving parts. Just a file that you can store on a shared network folder, etc. KeyPass desktop with the ability to share one of your secrets with someone else's database. Aug 22 comment Security considerations for partially shared password databases @AndrewSmith - what in blue blazes are you talking about?