Hi,
I have written this patch to be used with a hardware Crypto PKCS#11
accelerator
which can store keys. It is used in my company in TrustWay SSL accelerator
and,
TrustWay Apache-SSL accelerator with the Bull PCI CC2000 HSM.
Our HSM doesn't require C_Login. I believe that call to C_Login is
Hi, I am having problems with CHOICE in the following ASN.1 sequence:
-
DEFINITIONS IMPLICIT TAGS
Sub_seq200 ::= SEQUENCE
{
sub_field1 Sub_seq100 OPTIONAL,
sub_field2 [0] Sub_seq400 OPTIONAL
}
Seq1 ::= CHOICE
Hi !
When trying to build 0.9.7b fresh from the tarball by entering
ms\mingw32 on the cmd-prompt it stopped right before building
the static libraries when trying to remove the old ones.
My environment:
gcc.exe (GCC) 3.2.3 (mingw special 20030504-1)
Windows 2000 Professional fp3
openssl-0.9.7b
In message [EMAIL PROTECTED] on Thu, 26 Jun 2003 13:38:45 +0200, Michael Gerdau
[EMAIL PROTECTED] said:
mgd Applying the following patch did solve the problem. I have not
mgd checked wether this might happen with other Win32 environments too.
mgd
mgd diff -ur
Fernando,
I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be wrong
and don't have time to check right now (it's been a while ...).
So I think you want:
ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)
Frank
On Thu, Jun 26, 2003, Fernando Moya wrote:
Hi, I am having problems with CHOICE in the following ASN.1 sequence:
-
DEFINITIONS IMPLICIT TAGS
Sub_seq200 ::= SEQUENCE
{
sub_field1 Sub_seq100 OPTIONAL,
On Thu, Jun 26, 2003, Frank Balluffi wrote:
Fernando,
I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be
wrong and don't have time to check right now (it's been a while ...).
So I think you want:
ASN1_EXP(Seq1, value.field2,Sub_seq200, 0)
The default
My bad. The following attempts to describe EXPLICIT tagging of elements of type CHOICE:
FOO DEFINITIONS EXPLICIT TAGS ::=
BEGIN
Foo ::= SEQUENCE
{
foo1 [0] EXPLICIT Goo,
foo2 [1] IMPLICIT Goo -- Error: foo2 must be explicitly tagged.
}
Goo ::= CHOICE
{
integer1 [0] IMPLICIT
Thus spake David Maurus [EMAIL PROTECTED]
Stephen Sprunk wrote:
In the specification of CTR mode, as proposed for AES, you will find the
statement The number /nonce/ is incremented following each encryption.
I interpreted this to mean that the top 2^64 bits are to be incremented
for
each
Thus spake Michael Sierchio [EMAIL PROTECTED]
Argument: let's write an Internet draft that describes the use of AES CTR
mode in SSLv3/TLSv1. We can do it however we like, modulo the usual
criticism and review in the IETF working group(s).
Comments? Rich? Richard? Stephen?
I'm a bit more
Actually, SRTP was the first time I saw CTR mode and I believe it predates
NIST (i could be wy wrong there).
In SRTP, the counter is only 16 bits but that doesn't limit them to only
encrypting 64K blocks of data, it only limits them to 64K blocks *in one
rtp(udp) packet*. Obviously this isn't
Brian C Morris wrote:
Hi -
We're entertaining the possibility of porting openssl to the AS/400
(iSeries).
It seems from searching the archives this effort has been started before
- but I assume not finished as I don't see reference to the platform in
the code?
Is there still an
In message [EMAIL PROTECTED] on Thu, 26 Jun 2003 12:55:22 -0400, Lee Dilkie
[EMAIL PROTECTED] said:
lee_dilkie What I was trying (unsuccessfully) to make a point
lee_dilkie about. Please don't code up your CTR mode to *just* do the
lee_dilkie NIST or Ipsec version of CTR mode. Please code a
Hello Richard,
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED]
on Thu, 26 Jun 2003 12:55:22 -0400, Lee Dilkie [EMAIL PROTECTED] said:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future ways
of
Steven,
Stephen Sprunk wrote:
Thus spake David Maurus [EMAIL PROTECTED]
I assume that 'number /nonce/' should mean the result of the
concatenated parts of the IV.
No, in the proposal to NIST (by Lipmaa, Rogaway and Wagner), 'nonce' refers
to the top 64 bits and 'ctr' refers to the lower
Gtz Babin-Ebell wrote:
The application specifies 4 datas:
1. a step size
2. a bit mask.
3. a (optional) pointer to a function that is called if the
step bits that are not in the bit mask:
4. a (optional) pointer to a function doing the counting;
if (pCounter-Range)
return
Stephen Sprunk wrote:
I'm a bit more ambitious... We should specify NIST-style CTR mode for all
octet stream applications within the IETF's domain, with SSL/TLS as an
example. For record-based systems, I don't know if NIST-style or
IPsec-style would be more appropriate :-(
There is no such
Richard Levitte - VMS Whacker wrote:
OK, I've been follownig this discussion for a while, and it's time I
ake action. Basically, to provide for all the current and future ways
of handling the IV, I can see three alternatives:
- have the application provide a function that manipulates the IV.
-
In message [EMAIL PROTECTED] on Thu, 26 Jun 2003 13:31:37 -0700, Michael Sierchio
[EMAIL PROTECTED] said:
kudzu Richard Levitte - VMS Whacker wrote:
kudzu
kudzu OK, I've been follownig this discussion for a while, and it's time I
kudzu ake action. Basically, to provide for all the current
Richard Levitte - VMS Whacker wrote:
Whatever, I used the terms like this:
- IV is a bitstring of some sort (possibly random), of the same size
as the crypto algorithm block. In the AES case, it would be 128
bits.
- For CTR mode, the counter is a part of the IV. The rest of the IV
is
20 matches
Mail list logo
