by the codec.
Last year I worked on deniable voice authentication for Session Initiation of
the Axolotl-like email protocol without using PKI, but declined due to
insecurity. The idea is in document:
http://torfone.org/download/auth.pdf
Van Gegel
___
Messaging
Another approach with proposed scheme:
receiver can punctures decryption key regularly with known time-period. So
sender can manages PFS himself: send message with "best before" life-time
(while receiver still viable and honest of course). This can be useful in some
cases.
> Why is that more convenient for you?
This is a long story: the our software analogue of JackPair project
https://www.kickstarter.com/projects/620001568/jackpair-safeguard-your-phone-conversation
(modem problems still delaying the release of hardware by AWIT team).
We use another
s" <m...@bharr.is>
Date: 23 February 2016, 02:01:22
On 23 February 2016 at 08:02, Van Gegel < torf...@ukr.net > wrote:
Another problem: what is the minimum bit length of the hash (commitment) is
required for reliable verification by 32-bit short fingerprints of secret?
Not
I want to perform DH on the EC25519 and verify the secret using a short
fingerprint (32 bits SAS). Typically in this case the commitment needed for
preventing MitM by influence the responder's key after originator's key was
received.
To be securely the following scheme instead commitment:
hat the keypairs was
generated prior to learning the public key of the counterpart, then use a KDF
like scrypt or the new Argon2 on the shared secret which was generated to
derive the SAS. - Sent from my tablet Den 20 feb 2016 21:21 skrev "Van Gegel" <
torf...@ukr.net >:
I w
ice's initial message back to Alice,
and then reflect the hash back as well. The result is that Alice will complete
a protocol execution without Bob even existing. Is that bad?
Katriel
On Wed, 24 Jan 2018, at 10:45 AM, Van Gegel wrote:
Hi all!
Please advise on this protocol:
Two parties
Hi all!
Please advise on this protocol:
Two parties comparing 2 bytes short common secret using EC25519 (only mul and
mul_base procedures) and SHA3 hash.
Any side can be active adversary trying obtain secret.
c = H(secret)
Side A:
- picks a at random
- computes A = mul_base(a)
- computes A'
400 bytes of code. I was
check constant time on M0 using system ticks and compare some vectors with
twitamber library https://github.com/bernedogit/amber run on PC, all are OK.
This seems to be the simplest solution to password authentication.
Van Gegel
--- Original message ---
From: "
is it?
Van Gegel.
--- Original message ---
From: "Mike Hamburg" <m...@shiftleft.org>
Date: 8 March 2018, 21:11:42
Hello Van Gegel,
This seems reasonable, but it’s worth the exercise to prove security in order
to make sure there aren’t subtle attacks. For example, G and J must gene
her authentificator Ma=(S1 || G*b || J*b || Enc(X*a)) or Ma=(S2
|| G*b || J*b || Enc(X*a)) depends M1 or M2 matched or set Ma as random if not
matched
Alice send Ma to Bob
Bob check Ma ?= H(Sb || G*b || J*b || Enc(X*a))
This seems safe against partition attack but I'm n
or must select the sign(v) randomly to get a completely
random representation string of X25519 u-point with p2r()?
Thanks,
Van Gegel.
___
Messaging mailing list
Messaging@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging
?
Best regards, Van Gegel.
___
Messaging mailing list
Messaging@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging
Most messengers provide only the illusion of security. They sacrifice basic
rules for the convenience of ordinary users without caring for those who really
need security.
Really safe messenger MUST:
- never updated remotely;
- does not integrate with other services (for example, does not use
>What do you think about updates over Tor?
Updates via Tor is acceptable: at least this excludes targeted updates for a
specific user, which has already been practiced for compromise. It is better to
host the update server in onion.
>On the site I see mentioning of PGPFone. Is code related?
15 matches
Mail list logo
