Simple Encrypter and Decrypter Class
in [Java Programming]
|
Prev: [ANN] RefleX 0.4.0 released
Next: Exception questions
From: Arne Vajhøj on 26 Mar 2010 20:21 On 26-03-2010 17:37, Roedy Green wrote: > On Wed, 24 Mar 2010 20:47:42 -0500, Mike Amling<mamling(a)rmcis.com> > wrote, quoted or indirectly quoted someone who said : >> http://mindprod.com/products.html#TRANSPORTER" with no caveats about its >> weaknesses only encourages bad security. > > The proper place is in the product where it could stay up date. I think most users would prefer that the "This is really useless for serious use" disclaimer on the download page not something that they may or may not dig out after download. And there are really no update problem. An unsafe encryption solution will never become safe by magic. And if you do a new implementation, then that should not be mixed up with the old one anyway. Arne
From: Arne Vajhøj on 26 Mar 2010 21:02 On 26-03-2010 18:51, rossum wrote: > On Fri, 26 Mar 2010 15:23:21 -0700, Roedy Green > <see_website(a)mindprod.com.invalid> wrote: >> He also >> has to trust government and military experts not to withhold some >> secret technique to crack a proffered encryption algorithm or >> information about their advanced hardware abilities to crack codes >> (e.G. some sort of quantum cracking). > This is not sensible. The NSA suggested changes to DES and SHA-0 > which were later found to block certain attacks not publicly known at > the time, but obviously known to the NSA. Similarly GCHQ were aware > of public key cryptography before it became publicly known. > > If Govenment security agencies know something they will keep it close > to their chests until it becomes publicly known. True. And in any way it is completely pointless. What NSA may and may not know should not have any impact on the choice of algorithm, because you can only act based on information that you have. Arne
From: Roedy Green on 27 Mar 2010 13:51 On Fri, 26 Mar 2010 22:51:52 +0000, rossum <rossum48(a)coldmail.com> wrote, quoted or indirectly quoted someone who said : >>He also >>has to trust government and military experts not to withhold some >>secret technique to crack a proffered encryption algorithm or >>information about their advanced hardware abilities to crack codes >>(e.G. some sort of quantum cracking). >This is not sensible. The NSA suggested changes to DES and SHA-0 >which were later found to block certain attacks not publicly known at >the time, but obviously known to the NSA. Similarly GCHQ were aware >of public key cryptography before it became publicly known. > >If Govenment security agencies know something they will keep it close >to their chests until it becomes publicly known. I am saying you MUST trust your toolmaker if you use their tools. I am not saying it is foolish to trust. Creating your own tools creates its own set of serious problems. On the other paw, you can make fairly accurate estimates on how difficult it is to crack a given algorithm with a certain technology, but you are just guessing at how safe it is to trust some organisation including its ability to block infiltration. You are also just guessing on what secret and advanced technology those with very large budgets have. The actual threat is probably less than perceived for direct attacks and lower than perceived for betrayal. Use of open source is probably the best approach. Even if you don't detect the back door, or inadvertent/deliberate flaw, there is a good chance someone else will. If you were the US military, or the US government, would it not make sense to offer tools that appeared secure but that allowed you to read everyone else's messages. There is certainly motivation to do that. They have even done that explicitly and openly in past. -- Roedy Green Canadian Mind Products http://mindprod.com If you tell a computer the same fact in more than one place, unless you have an automated mechanism to ensure they stay in sync, the versions of the fact will eventually get out of sync.
From: Arne Vajhøj on 28 Mar 2010 20:34 On 27-03-2010 13:51, Roedy Green wrote: > On Fri, 26 Mar 2010 22:51:52 +0000, rossum<rossum48(a)coldmail.com> > wrote, quoted or indirectly quoted someone who said : >>> He also >>> has to trust government and military experts not to withhold some >>> secret technique to crack a proffered encryption algorithm or >>> information about their advanced hardware abilities to crack codes >>> (e.G. some sort of quantum cracking). >> This is not sensible. The NSA suggested changes to DES and SHA-0 >> which were later found to block certain attacks not publicly known at >> the time, but obviously known to the NSA. Similarly GCHQ were aware >> of public key cryptography before it became publicly known. >> >> If Govenment security agencies know something they will keep it close >> to their chests until it becomes publicly known. > > I am saying you MUST trust your toolmaker if you use their tools. Not really. Good encryption stuff uses public known algorithms that have been reviewed by researchers worldwide. And implementation can (read: should) be available in source form for review by developers worldwide. > Use of open source is probably the best approach. Even if you don't > detect the back door, or inadvertent/deliberate flaw, there is a good > chance someone else will. > > If you were the US military, or the US government, would it not make > sense to offer tools that appeared secure but that allowed you to read > everyone else's messages. There is certainly motivation to do that. > They have even done that explicitly and openly in past. Reference? Arne
From: Arne Vajhøj on 28 Mar 2010 20:49
On 24-03-2010 16:46, Roedy Green wrote: > On Wed, 24 Mar 2010 16:15:07 +0000, rossum<rossum48(a)coldmail.com> > wrote, quoted or indirectly quoted someone who said : >> There are >> 1001 free implementations of Base64 out there. > > see http://mindprod.com/jgloss/base64.html for some of them. > > I wrote one myself. > > I have not run across any comparison of their speed or quality. I find it difficult to see any reason not to use the standard Java EE API for this. Arne |