On Thursday, August 20, 2015, Tommi Prami wrote:
> Just my 0.02€
>
> http://ianix.com/pub/chacha-deployment.html
>
> ChaCha20 is in TSL and OpenSSH etc. and mainly because it is secure and it
> is fast.
>
>
> I wasn't aware of that. Very, very cool.
--
Jim Starkey
Just my 0.02€
http://ianix.com/pub/chacha-deployment.html
ChaCha20 is in TSL and OpenSSH etc. and mainly because it is secure and it
is fast.
-Tee-
On Thu, Aug 20, 2015 at 2:26 PM, James Starkey wrote:
>
>
> On Thursday, August 20, 2015, Michal Kubecek wrote:
>
>> On Wed, Aug 19, 2015 at 02:
On Thursday, August 20, 2015, Michal Kubecek wrote:
> On Wed, Aug 19, 2015 at 02:55:33PM -0400, Jim Starkey wrote:
> >
> > The best alternative to RC4 is AES-128. It is "more" (but not
> > measurably) secure but also a couple of hundred times as expensive to
> > compute. If you don't believe me
On Wed, 19 Aug 2015 14:55:33 -0400, Jim Starkey
wrote:
> You're excessing fussy. No one has ever found a SHA1 collision, let
> alone a bogus hit. It is perfectly secure. It has known weaknesses,
> but even with these known weaknesses, it is impossible to crack.
>
> RC4 is perfectly secure.
On Wed, Aug 19, 2015 at 02:55:33PM -0400, Jim Starkey wrote:
>
> The best alternative to RC4 is AES-128. It is "more" (but not
> measurably) secure but also a couple of hundred times as expensive to
> compute. If you don't believe me, run your own numbers.
I did...
mike@unicorn:~> openssl sp
You're excessing fussy. No one has ever found a SHA1 collision, let
alone a bogus hit. It is perfectly secure. It has known weaknesses,
but even with these known weaknesses, it is impossible to crack.
RC4 is perfectly secure. It is vulnerable to correlated keys as used in
WEP. But SRP use
27.07.2015 17:07, Jim Starkey wrote:
> Question: Does Firebird detect, report, and shutdown repetitive attacks
> on passwords?
Yes, it does (in single-process architectures).
Dmitry
--
Firebird-Devel mailing list, we
On Monday, July 27, 2015, Alex Peshkoff wrote:
> On 07/26/2015 10:00 PM, Ivan Arabadzhiev wrote:
> > Personally, I've recently started using (mostly for kicks) things like
> > https://en.wikipedia.org/wiki/Scrypt
> > https://en.wikipedia.org/wiki/Bcrypt
> > https://en.wikipedia.org/wiki/PBKDF2
>
On 7/27/2015 8:35 AM, Alex Peshkoff wrote:
> On 07/26/2015 10:36 PM, Jim Starkey wrote:
>
>> The bottom line is this: If you are going to change the password hash,
>> you are going to invalidate all existing passwords. But rather than
>> start over with an already flawed architecture, punt on sto
Internet connections typically pass through a dozen routers, any of which could
be configured to mount a man in the middle attack. The most important thing to
get right is the security handshake. If that's weak, nothing else matters.
I agree. I, and I believe the original proposal, was mostly
Not saying I want/need that for the moment, but you did ask for
suggestions. And yes, the exact purpose of slow hashing is to make
bruteforce attacks harder both with legit client attempts to authenticate,
and when/if the user database is compromised. The latter might be a more
valid reason to swit
On 07/26/2015 10:00 PM, Ivan Arabadzhiev wrote:
> Personally, I've recently started using (mostly for kicks) things like
> https://en.wikipedia.org/wiki/Scrypt
> https://en.wikipedia.org/wiki/Bcrypt
> https://en.wikipedia.org/wiki/PBKDF2
> I suppose the option to tune them in the future (or even in
Sorry, you got taught wrong. Security is about the whole system, not one
piece. Hash based security is vulnerable during password exchange, which a
slow hash doesn't fix.
Internet connections typically pass through a dozen routers, any of which
could be configured to mount a man in the middle at
On 07/26/2015 10:36 PM, Jim Starkey wrote:
> The bottom line is this: If you are going to change the password hash,
> you are going to invalidate all existing passwords. But rather than
> start over with an already flawed architecture, punt on storing
> passwords at all and go exclusively with S
> Really? Could you explain why an authentication scheme whose primary claim
> to fame is
> its high computational cost is a good choice for a database system that needs
> to do
> hundreds of authentications per minute or second?
I've been taught that the hashing function for passwords should
On Sunday, July 26, 2015, Jiří Činčura wrote:
> > Personally, I've recently started using (mostly for kicks) things like
> > https://en.wikipedia.org/wiki/Scrypt
> > https://en.wikipedia.org/wiki/Bcrypt
> > https://en.wikipedia.org/wiki/PBKDF2
> > I suppose the option to tune them in the future (
> Personally, I've recently started using (mostly for kicks) things like
> https://en.wikipedia.org/wiki/Scrypt
> https://en.wikipedia.org/wiki/Bcrypt
> https://en.wikipedia.org/wiki/PBKDF2
> I suppose the option to tune them in the future (or even introduce a
> configurable
> parameter) is also
On 7/26/2015 2:38 PM, Alex Peshkoff wrote:
> On 07/26/2015 01:39 PM, James Starkey wrote:
>> If you were starting over from scratch, you wouldn't want to use SHA-1 to
>> avoid wasting time with discussions like this. See also RC4. But the
>> problem with SHA-1 doesn't justify the inconvenience of
Personally, I've recently started using (mostly for kicks) things like
https://en.wikipedia.org/wiki/Scrypt
https://en.wikipedia.org/wiki/Bcrypt
https://en.wikipedia.org/wiki/PBKDF2
I suppose the option to tune them in the future (or even introduce a
configurable parameter) is also a plus.
2015-07
On 07/26/2015 01:39 PM, James Starkey wrote:
> Get real. Read about the actual problems. Bthe issue is that there is a
> theoretical problem that a manufactured duplicate collision could be
> manufactored in something like time 2^82, something that nobody has
> actually be able to do.
>
> Sure, SH
Get real. Read about the actual problems. Bthe issue is that there is a
theoretical problem that a manufactured duplicate collision could be
manufactored in something like time 2^82, something that nobody has
actually be able to do.
Sure, SHA-1 has a known weakeness. It's replacement probably ha
I have brought this up before, and it might be a bit annoying that I do
so again, but I remain concerned by the fact that we are about to ship a
product (Firebird 3) that uses hashing and encryption algorithms (SHA-1
and RC4) that most in the industry consider outdated and (relatively)
insecure
22 matches
Mail list logo
