Re: [freenet-dev] Freenet Security Setup update
On Sunday 10 Mar 2013 03:33:08 Steve Dougherty wrote: > On 03/06/2013 04:29 PM, irfan mir wrote: > [snip] > > This time, I made quick mock-ups that get the idea across as it > > was brought to my attention that in the past others have provided > > shiny designs, but not development. That made me feel sad and I > > decided I am going to work on the interaction design and > > development more than the visual aspects form now on and do as much > > as I can and know how to do. > > > > The mockups and descriptions of what is happening are as follows: > > > > This is a mockups of the structure of the security setup when it > > loads: http://cl.ly/image/0O0d0H3Z2C39 > > > > I was thinking about changing the questions to ' I know someone > > who runs Freenet ' and ' I use full-disk encryption ' to make it > > more clear that checking / ticking the checkboxes answers the > > questions. What do you think? > > Sounds good to me. I appreciate the focus on getting something > functional first - it's more immediately useful. This project has lots > of ideas - it also needs people that can _implement_ ideas! > > One thing I wonder about though is if it will be clear that this is a > series of questions instead of requirements. > > > Also, the ' question-mark icon ' in the lower-right corner of the > > above mockup provides the user some assistance if they are > > confused by the questions. On hover of that question-mark a tooltip > > appears explaining that answering these questions allow for the > > appropriate security options to be displayed and clicking goes > > straight to all the security options. > > What is your reasoning for single question mark? I would have expected > an expandable explanation beneath each question. > > > If the user leaves both checkboxes unchecked, as far as my > > understand goes, they can only have Low Security so that is all > > that is offered to them: http://cl.ly/image/2p2r0I0Q191I > > > > If the user checks one of the boxes, they get more options to > > choose from: http://cl.ly/image/3E23290N241R > > > > If the user checks both boxes, they are presented with all the > > options: http://cl.ly/image/1f1O0W3N333H > > > > And, lastly, upon checking or selecting one of the security > > options, in this case ' Low Security ', input-fields appear > > underneath for the users to entre their security preferences: > > http://cl.ly/image/3J2h0n081732 > > This looks like asking questions in addition to the security level > selection. What I was proposing was asking questions instead of the > security level selection. It seems like it would guide someone through > the decision process more, and the question explanations should be > able to make clear the implications of each choice. > > --- > > 1) I know someone who runs Freenet. > > If you already know someone who runs Freenet, and are pretty sure > they're not malicious or incapable of securing their computer, it's a > good idea to connect directly to them as a "friend connection." Using > entirely friend connections provides much higher security as it makes > it more difficult for malicious people to join the immediate network, > and it removes dependence on Freenet Project volunteers' central > servers for finding initial connections. > > (Can in the future offer to take a one-sided invitation from another > node or groups of nodes. Is it useful to take noderefs now in that > it'll be easier to have the currently installing node operator just > have to share their reference?) In future we will have invites, which will include multiple noderefs, yes. I guess we want a form to upload an invite if we have one already? In some cases we will provide an installer complete with noderef but this may not always happen... > > 2) I am willing to connect to untrusted strangers. > > If you don't know around three to five people who run Freenet already, > it won't be enough to connect only to friends. As a less secure > convenience, Freenet Project volunteers run servers which help in > gaining initial connections. While convenient for you, it's also > convenient for malicious people as they can track activity more easily. > > (Low or normal network security.) Right. Even if you have an invite, you may want to choose normal anyway for better performance. If you don't have an invite you need normal. > > 3) I prefer extreme network security at the expense of even more speed. > > Freenet shares network information with other computers it connects > with to improve performance. Even though this information is limited > and almost always safe to share, in extreme cases you may want to not > share it to gain more network security at a significant cost in > performance. > > (Maximum network security. Requires #1. How best to show this? Does it > appear under #1 only when #1 is checked?) I don't see why we need to ask about maximum. We don't at the moment, unless you choose custom. > > 4) I use full-disk encryption. > > Network security d
Re: [freenet-dev] IllegalKeySizeExpeption
Yes, adding padding to RSA is on our todo list. Perhaps we will just use 128 bit AES. If either of you feel like submitting a patch to address these issues it would be appreciated. Ian. On Sun, Mar 10, 2013 at 4:58 AM, Florent Daigniere < nextg...@freenetproject.org> wrote: > On Sat, Mar 09, 2013 at 08:19:26PM +, Matthew Toseland wrote: > > On Saturday 09 Mar 2013 15:43:11 Ian Clarke wrote: > > > We've been running into an IllegalKeySizeExpeption with Tahrir, which > > > requires that anyone outside the US download the Java Cryptography > > > Extension - obviously this is unacceptable from a usability > perspective. > > > > > > How does Freenet address this problem? > > > > I assume you are trying to use 256-bit AES? > > > > Options: > > > > 1. Just use 128-bit crypto. This is 30%-40% faster than 256-bit, and > should still provide adequate security, according to nextgens. > > > > 2. Use 256-bit crypto via the Bouncycastle lightweight API. This is not > subject to keylength restrictions. Obviously you'll need to ship the jar. > > http://www.bouncycastle.org/documentation.html > > > > 3. Provide your own crypto libraries. > src/freenet/crypt/ciphers/Rijndael*.java > > > > Complications: > > > > First, be careful with the key size of the various components, the > limiting factor is usually not the symmetric crypto, see e.g. > > http://www.keylength.com/en/3/ > > > > Second, use AES, i.e. 128-bit block size. 256-bit block size is used in > Freenet at the moment and this complicates matters considerably; until > Eleriseth's recent changes it was dramatically slower than using the > standard 128-bit block size. > > > Hi Ian, > > Let me translate: two choices: > - Use 128bit crypto (no export restriction, faster and ok unless > you assume that the attacker has access to a quantum computer way more > powerful than anything publicly known) > - Don't use JCA > > > https://github.com/sanity/tahrir/blob/master/src/main/java/tahrir/io/crypto/TrSymKey.java > > https://github.com/sanity/tahrir/blob/master/src/main/java/tahrir/io/crypto/TrCrypto.java > Glancing at Tahrir's crypto , you have much bigger problems than the > key-size choice... > 1) "RSA/None/NoPadding" is never okay. Padding is critical to RSA's > security. You want OAEPSomething. ( > http://rdist.root.org/2009/10/06/why-rsa-encryption-padding-is-critical/) > 2) Unauthenticated encryption is a bad idea... You really shouldn't use > AES/CBC without integrity verification ( > http://meri-stuff.blogspot.com/2012/04/secure-encryption-in-java.html). > If I were you I'd got for authenticated encryption AES/CTR/CCM or something > like that. > > Really, if you want to keep it simple, use a higher level encryption > library (Keyczar, cryptlib, NaCL, the bouncycastle's high-level stuff, > apache shiro, ...). > > Regards, > Florent > ___ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Ian Clarke Personal blog: http://blog.locut.us/ ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
