hai..
is the issue solved?
Pada Selasa, 08 Januari 2019 pukul 05.19.33 UTC+7 kortschak menulis:
> The problem with this approach is that something that's good enough for
> This Use™ by the owner of the code will be seen by another person and
> then used by someone else with less understanding. Th
The problem with this approach is that something that's good enough for
This Use™ by the owner of the code will be seen by another person and
then used by someone else with less understanding. The world of
cryptography implementations is already contaminated enough with badly
implemented Correct™ s
On Friday, December 4, 2015 at 5:33:45 PM UTC-5, Jeff wrote:
>
>
> "My question for the original poster is whether he needs to maintain
> compatibility with a legacy system, or whether he is looking for a good
> system when starting from scratch."
>
> it will be a new system that will import exi
Yes, thanks for the refresher. ;-)
But as I said, for non-crypto requirements weak data (or password)
obfuscation can be sufficient.
For such weak purposes an FNV-1 code 3-liner may be adequate.
For comparison: The Argon-2 github shows about 2000 lines of C code.
Am Montag, 7. Januar 2019 16:
I spent most of November studying password hashing and IMO argon2id should
be used for new projects going forward. Very nice implementation in Go in
the x library. I don't speak Java so can't help you there.
--
You received this message because you are subscribed to the Google Groups
"golang
On Mon, Jan 7, 2019, at 07:58, minfo...@arcor.de wrote:
> I've often encountered demands for password encryption, where simple string
> hashing would suffice.
You should never encrypt passwords; encryption implies that you can get the
original password back out, it's a two way street.
Some form
On Mon, 7 Jan 2019 at 13:58, wrote:
> I've often encountered demands for password encryption, where simple
> string hashing would suffice.
>
> Speed-wise FNV-1a is barely to beat. Add some magic number to the
> result and you are good enough.
>
Not for password encryption. FNV isn't designed for
I've often encountered demands for password encryption, where simple string
hashing would suffice.
Speed-wise FNV-1a is barely to beat. Add some magic number to the
result and you are good enough.
The algo fits in a single handful of lines.
Of course this ain't military strength encryption, but
Have you get a solution? i have the same problem too, golang is not
compatible with java SecretKeyFactory
在 2015年12月2日星期三 UTC+8上午7:47:22，Jeff写道：
>
> I'm am looking to implement in go, the following code written in Java.
> I have not been able to find any apis or modules for this. Is it
> possi
