I for one am not happy with the choice. It's slower in software than
blake or skein, and on ARM it's even slower than SHA-2.
I'm not convinced that using a construction that's significantly
different from MD gains us much. The constructions are often provably
secure, so we only need to care about
> In that you see the selection of Keccak, focusing more on its high security
> margin, and new defenses against existing known types of attacks.
Is the margin really larger than the margin of Skein or Blake?
> And CPUs are getting faster all the time
The problem is the amount of data we work wit
You could look into CurveCP for inspiration. It's UDP based, and its
connections survive if the IP of the client changes. That's because it
uses the client's public key as connection identifier instead of the
IP.
But you can't use it directly, since you need FIPS ciphers. You'll
also need to imple
I didn't look at your code, but from what I remember oplop is a silly scheme:
1. Doesn't strengthen the password (Uses MD5 instead of PBKDF2, scrypt,...)
2. No clean domain separation between username and password
3. The algorithm that ensures that the password contains numbers is really weird
One could require the user to specify/confirm a certificate fingerprint on
gmail in such a case. That way you're MitM proof, even with a self signed
certificate.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/l
You're using a classical merkle tree which has only two tags, one for
leaves, and one for inner nodes.
This doesn't have any practical weaknesses, but lowers second pre-image
resistance from 2^256 to (2^256)/n. For realistic
input sizes that's still above 2^200, so it doesn't really matter.
I belie
A naive implementation has a cost of 2^b: Using memory m it takes time
(2^b)/m keeping the product constant. These trade-offs are harmless.
A more sophisticated implementation is:
1. Run the sequential squaring algo, but only store every 2^{b/4} value.
This takes around 2^{b/2} time and 2^{b/4} m
1) If you want to prevent tampering, use a MAC, not a cipher. My
recommendation is HMAC-SHA-2. Be sure to use a constant time equality check
while verifying the MAC.
2) If you want to encrypt something symmetrically, use authenticated
encryption. Either with a specialized mode, like AES-GCM or with
There are many details that are not clear to me. Typical Curve25519 usage
deviates from typical NIST curve usage in several ways:
1. montgomery form, not weierstrass (conversion probably possible, never
looked into details)
2. custom serialization format for public keys (32 bytes little endian,
re
> If that is all you want, have you considered SipHash? It is much faster
> than the other algorithms, yet more secure than CityHash, Murmurhash and
> friends. And it provides an IV/salt to make it per instance unique.
Is SipHash really that fast in this context? AFAIK it's only much
faster for sh
My argument concerning performance is that for long messages SipHash
isn't actually significantly faster than (possibly round reduced) MD5,
Skein, Blake2 etc.
The main selling point of SipHash is that it's faster than normal
crypto hashes for short messages. Since ZFS almost always hashes long
mes
On Sun, Nov 10, 2013 at 9:54 AM, Andy Isaacson wrote:
> For example, suppose you use the low bits of the bitcoin blockchain
> hash. An attacker with 10% of the hash power could probabilistically
> attack such a system by chosing blocks with a specific value in those
> bits;
This can be avoided b
On Mon, Nov 11, 2013 at 8:14 PM, Natanael wrote:
> Proof-of-work, just like Bitcoin itself uses for hashing?
No this idea isn't about proof of work. The idea is delaying the
computation result, preventing a miner from picking a value.
If the computation takes an hour on the fastest available compu
>> Right, that I agree with. Packets should be deterministically created by
>> the sender, and they should be verifiable by the recipient.
>
> Then you lose the better theoretical foundations of probabilistic signature
> schemes ...
If you drop receiver verification as a requirement, you can deri
Have you considered a patent licence that applies to all open source
software, similar to Rogaway's OCB License 1?
http://www.cs.ucdavis.edu/~rogaway/ocb/license1.pdf
It has a clause that the whole software needs to be open source, not
just the library, so it's similar to GPL in that regard.
But
15 matches
Mail list logo
